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!
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:
- There are lots of integrations all in one plugin.
- That means there are tons of configuration options.
- That means the README is crowded with all sorts of facts and demos.
- 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.
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 makeintegration 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.