![](https://social.packetloss.gg/pictrs/image/37d4c04b-5a9a-4a2e-a449-7a0a4aacf182.png)
![](https://programming.dev/pictrs/image/8140dda6-9512-4297-ac17-d303638c90a6.png)
There is more value in understanding how to extend and customize your editor than in searching for a new one. Use whatever your workplace provides the best support for, and then customize it from there.
I think there’s something to be said for shaking up your environment periodically as well and trying new things. Sure, there’s a week where you edit at a snails pace, followed by a month where you edit a bit slower than normal, but different tools really do have different pros and cons.
For the code bases I’ve worked in, this evolved from necessity as the code files were so large many editors were struggling, the rules for the style so custom that editors can’t be properly configured to match, or the editor performance in general was questionable.
I went through a journey of sorts from IDEs to Electron based editors to Emacs and currently am working with Kakoune (and I’ve passed over a bunch of other editors like Sublime, Helix, and Zed that couldn’t meet my requirements or didn’t match my sensibilities – even though a thing or two here or there really was excellent). Pretty much every change has been the result of the editor pain points that couldn’t be addressed without actually working on the editor itself.
I’ve mostly just tweaked the configuration and built my own comment formatter/reflow command based on the comment style at work.
It’s almost more about what it doesn’t have for me, because what I’ve run into a lot with trying newer editors is they try and manage the code too much and the code base at work has its own style guide that doesn’t match what the editor tries to do. So the editor might make me slightly more productive … until I find myself fighting with it every 3 lines because of auto formatting or some language server quirk.