Ideas for improving editor experiences

A woman I know recently tried to learn Elm, but she got stuck setting up her editor. She ended up giving up on the guide at that point! :scream:

This made me really motivated to improve the editor experience, so I started looking into the Sublime Text plugin to try to figure out how to do that.


It is really hard to get started because:

  1. There are lots of integrations all in one plugin.
  2. That means there are tons of configuration options.
  3. That means the README is crowded with all sorts of facts and demos.
  4. Some of the older integrations are out of order in various ways.

When I am learning a new editor, it is really hard to just figure out how to install a plugin. By the time I figure that out, I am done messing with settings for the day. I just started learning the language, so I am not interested in advanced workflow keyboard shortcuts yet.

Alternate Design

After reviewing the Sublime Text plugin, I ended up thinking it’d be good to split it into four smaller plugins:

I think this design is a good balance for beginners, professional developers, and editor enthusiast.

  • Beginners just get going with Elm Syntax Highlighting. README focuses on how to install.
  • Professional developers can get elm-format and elm make integration as needed. By having it be separate plugins, the README can focus on teaching the more advanced capabilities of the editor (e.g. learning some keyboard shortcuts) without overloading them.
  • Editor enthusiasts still have free range to implement more complicated and more experimental features. Folks will be coming from the smaller three plugins, and therefore will be more prepared to change settings, learn keyboard shortcuts, etc.

So that path is already partly implemented for Sublime Text, but I am interested in getting a consistent experience across editors.

Consistency across editors

I think it would be really great if the experience was consistent across editors. This way you could switch between companies/teams/projects more easily. This is especially nice when pairing with someone at work or at a meetup.

I also think it’d be great to have a way to encourage good performance. If people end up using a editor plugin with performance issues (operations >500ms and/or high RAM usage and/or battery drain) they are very likely to mistakenly think that these are facts about Elm.

So I started making some specifications that maybe could help us get really nice editor experiences across a broad range of editors:

I am curious to hear feedback on this repo from authors of editor plugins, and people who are currently light users of editor features.


Very interesting.
There is elm-language-server. Very simple to install and to setup (at least on VS Code) wouldn’t something like that do the trick ?

I think that something like parcel - zero configuration, could be better.

So there is one package, but other sections like format and save are in advanced or folded.

If elm or elm-format is detected, it is used. Otherwise just remains folded.

1 Like

IMO the spec looks like a great idea. For example for Vim @andys8 split the syntax highlighting and indentation to, and the rest is up to power users.

For example I do formatting and errors in the editor with vim-ale, elm-format, and elm-make. Andy and others are instead putting a lot of effort into the language server setup and have some instructions here for more in depth configuration.

There may be some details that are done differently on the editor communities.

For example, in vim many plugins shy away from providing a default key binding that could override one you have set up. Or on vscode it seems the language plugins favor having just one bit plugin for all the language features that usually work with a language server that is auto installed.

I may be good to let plugins on the list if the divergence from the spec is justified by the editor community norms and the experience is still good.

I haven’t tried Sublime with Elm yet, but I found both the Atom and VS Code setups for Elm to be very pleasant due to their simplicity and easy of use.

I know there’s been a lot of work on the Elm Language Server and that it has support for Vim, Emacs, VS Code, Sublime, and more. The only part I could find difficult with it in VS Code (where I use it) is it by default expects everything (elm, elm-format, etc) to be installed globally, which would cause the user to have to configure it manually.

I personally prefer 1 plugin per language so that there’s less confusion about what I need to install in order to use the language. Something along the lines of Parcel. Though even that can run into issues where you have to wait for Parcel to upgrade before you can use a new tool.

1 Like

So you want people to not get into configuration but don’t want them to have this cool auto-format feature they see on YouTube as built-in? how auto-formatting is “professional” only? I think it’s a great catchy asset when starting with Elm.


I have a plan for autodetecting these from your local npm dir, but I need time to implement it.


autodetecting these from your local npm dir

This would be amazing and simplify user experience a lot.

I would guess that incorporating tools like elm-format into the elm CLI would be more beneficial as then a user who installs elm (which is required) would automatically get formatting. No need to read separate documentation or hunt down separate installs.


I think this is the crux of the issue with a lot of plugins.

For my personal preferences, when I start with a new language I just want to be able to build the simple “Hello World” file from the editor. I code a little, build, change, build, change, etc. It is a conversation with the compiler and I don’t want to have to leave the editor for this. I view this functionality as a MUST for absolute beginners. When I was starting out, this was the reason why I chose SublimeText over Atom. I could not figure out how to make Atom build on demand.

In my perspective, the syntax highlight, elm make and elm-format belong in a single “Elm support” plug-in. The only configuration for this plugin would be the elm-format on-save toggle which could be false by default to not confuse absolute beginners.

The problems like bad performance, battery drain and fighting with the autocomplete come ONLY when you bring in project analysis. That should be delegated to an advanced support plugin.

1 Like

I like the overall idea, though the specifications should be careful with being platform dependent. For example:

MUST run elm make --output=/dev/null --report=json $CURRENT_FILE_PATH from $CURRENT_FILE_DIR.

should use a command ala elm make --output=NUL --report=json $CURRENT_FILE_PATH on Windows.

OK, few more thoughts because I don’t agree on separation of features throughout various plugins.

How useful to a beginner is just a syntax highlighter vs syntax highlighted code completion? Here’s new video of plugin for IntelliJ

AFAIR in Sublime Text 3 you have to install Package Manager first? How’s that easier?

And last, to me, installing some language plugin for editor and seeing it’s useful for nothing else than seeing colors of letters is huge disappointment. On the other side, beginner in programming does not even know the “syntax” word, so it’s hard to explain to him/her that “syntax highlighter” is just colors, not auto-importing packages or renaming things like on YouTube video he/she saw.


I agree editor installation/configuration can be a barrier to uptake and something that would serve a growing Elm community well if it could be streamlined.

I would distinguish between barriers for moderately experienced developers who are coming to Elm for the first time and barriers for those who are new to coding who are using Elm as their first language.

I do a lot of teaching of students in this second group and have chosen Elm as its compile-time hand-holding and error messages make it a great language for learning with. We developed litvis (literate Elm) partly to support this group, but I dislike having to spend the first session with students explaining and fixing Atom or VSCode configuration issues (steps 1-5 here).

My experience with complete beginners working with Elm is that Elm Format is probably more important than syntax highlighting as consistent page layout is helpful in reinforcing and supporting learning the language. I suspect that complete beginners are less sensitive to plug-in performance issues than more experience developers moving to Elm, so I think could be a cost worth bearing if it smooths that initial experience.

I am also a fan of Elm Format’s zero-configuration philosophy, which while prescriptive, avoids the need to document config options and waste valuable cognitive effort in choosing how and whether to config.

Prior to working with Elm I spent a decade teaching new programmers Java using Processing. One of the great benefits of this environment is that with a single one-step installation, the entire self-standing IDE was available. Students could be up and running, coding their first working examples within their first 5 minutes of exposure to the environment. Perhaps Elm could offer something similar?


should use a command ala elm make --output=NUL --report=json $CURRENT_FILE_PATH on Windows.

From what I can tell /dev/null is actually recognized and treated specially by the Elm compiler, since --output=/dev/null does in fact work on Windows to prevent output (and --output=/dev/blah gives an error message).

1 Like

Absolutely hard agree with this. Having taught a few bootcamps for non-programming undergrads, the syntax errors and general poor formatting lead to the most amount of confusion.

Experienced programmers might dislike elm-format because they have some pre-existing ideas of how they want their code to look, beginners don’t and won’t care that a tool makes their code look a particular way.

1 Like

After almost two decades of development and continuous research, the best rule I learned for formatting is to follow the accepted standard unless you are in a team that doesn’t follow the community accepted formatting. So, I totally support that an individual’s liking or disliking shouldn’t be taken into account unless he or she is creating a team and decides not to follow the community accepted formatting.

I don’t know if I understood properly, but I find these two contradictory. If poor formatting leads to confusion then enforcing elm-format should help.

1 Like

I’m saying beginners won’t be opinionated about elm-format, so there’s no reason to not use it by default.

My point is elm-format should be opt-out not opt-in.


As others said, I think the best idea would be to have a zeroconf “Elm support” with format syntax and make, and an “Elm advanced tools” based on ElmLS and supporting everything, maybe even configurable

When starting with a new language the biggest point of confusion in the editor is when there are multiple extensions for it. Without additional context I have no idea which one I should install – is one newer than another one? is one for more advanced features? do they overlap?

As others have mentioned, having auto-formatting and a language server only makes it easier to get started with a language. You get more hints, faster feedback when you do something wrong and the formatting means that your code looks similar to any examples you come across in docs etc.

The ideal for me would be a single zero conf extension which installed everything, elm make, elm format, elm language server. They would all work without additional installation of external dependencies and for the advanced user any of the features could be disabled if desired. Adding “official” to the name would be a useful hint as well.


One consideration is also the number of tools to download and setup outside the editor. For example, elm-format being separate from the elm binary. And to use the REPL, I also need to install Node.

I think it would be nice to know more about what the flow of learning we want to improve actually is. Did this person go through the book and got stuck on the editor setup? Or did she start somewhere else?

If she was going through the book, maybe the coding experience in there is more important to simplify? Going through the beginning of it now, it feels surprising that I’m not able to just run the embedded code samples from inside the window, ala what I can do in Rust. Especially the REPL seems ideal to have embedded in the book. I know when I started out with coding, the terminal was this strange and scary thing that wasn’t exactly an inviting piece of software (to me anyway). I would probably be nervous at the prospect of having to use that via the REPL to follow along, whereas just typing into a text field in my browser would not be scary at all.

If this person felt the same way about things like: number of tools, terminals, abbreviations like REPL, maybe trying to understand what Node is, etc., then by the time she reached the section on setting up her editor, she may have been quite spent already.


Having a entry level tool and an advanced tool also might just cause the entry level one to be broken most of the times.
I don’t think most people that are new to a language would report errors in the first few hours and all advanced people would just use the advanced plugin. And it’s already kinda hard to maintain the tool we have, adding more won’t make that better.

(on a side note, if anyone want’s to join the tooling effort, please let us know, best would be to post in the slack channel for #editors-and-ides)