I disagree here. Syntax highlighting is very solid and running Elm binaries separately is never broken because it is not on the editor.
On the other hand I’ve had to deal with broken LSPs, and plugins, CPUs pegged at 100%, and a bunch of other things I’m both vim and vscode, and even as an advanced user every time the tools break it is super frustrating and hard to even know what to do most times.
If entry level tooling means syntax highlighting and run Elm from the cli, I doubt it will ever break or cause unexpected errors or interactions,
But practically, how would that go ? Should I do everything in that order:
update the specs first
then when OK, make the whole thing robust and tested
at that moment I publish on Sublime repo
when public, I make a PR to add it in the editor repos’ README ?
Fine by me if that’s what everyone wants, or maybe small stuffs like these and maybe the snippet plugin in Sublime, should remain separate, opinionated things?
Another possible improvement could be having new projects started from elm init include an EditorConfig file. This could configure things like tabs vs. spaces, to alleviate some of the pains you might run into when trying to configure your editor.
I am setting up some meetings to talk with some of the authors of various editor tools and plugins.
One of the big lessons of this post was the large diversity of perspectives on this topic. After talking with one of the developers of the IntelliJ plugin, I suspect further face-to-face discussion will lead to a better proposal than the one that started this thread!
I’ll post another thread once there is enough progress with these conversations!
