Alternatively, this could be an LSP code action. Requires more manual work from the user but it would be less surprising.

Some editors sometimes have a "Convert to snake_case" command which solves the problem, but it's not necessarily discoverable. Took me a few days to discover mine had that. An LSP code action would be a lot more discoverable.

Sounds good to me! I think we would only want to do this for definitions and not for referencing variables and functions. What do you think?

We'll need to make the parser permit uppercase names have the analyser emit an error if one is used in a definition.

I could see it used for both definitions and references, but I do imagine this being more surprising or annoying for references. I think it would be reasonable to start only with definitions, and at some point to have a branch where it also does it for references, and try to see how it feels.

Although it should probably be tried out by beginners, as seasoned Gleam developers will likely not write camelcase already (unless they also often work with camelcase languages).

For references it could "correct" to a value that type checks but isn't the value that the programmer intended to use. I'd like to not have anything that could make the programmer's code silently do the wrong thing.

I might try and tackle this one. Should I implement it in the formatter or in as an LSP action?

And should I take a look at what was suggested in #2998, and change this error to occur in the analyser?

Thinking about this more, I think this should be an lsp action, since the job of the formatter isn't really to fix errors in code.

Yes I think so too!

One question about the implementation of this: Should I unify the three name token types and only discriminate between them later, or keep them and just not report any errors until the analyser?

Keep them distinct please. The change to the codebase should be small.