What I Expect from an Editor as a Programmer
Perhaps I can still teach this old dog a few new tricks?For the past 25 years, I’ve primarily worked with just one program editor in my professional life: the VB6 editor. But my journey began much earlier - in the early 90s. Back then, things were a bit simpler, or at least more straightforward.
Initially, it was just a plain text editor. The first environment worthy of that name was PDS 7.1, Microsoft’s BASIC Professional Development System, which-despite running under DOS-already featured the window layout we still know today from Microsoft environments like VB to Visual Studio, and which has been widely adopted. In that environment, I felt right at home.
And that’s exactly what I’m trying to analyze in this article: What was it that made me feel that way? What do I expect from my programming editor? And how can I configure Emacs to seamlessly handle all these tasks?
Window Handling
As a rule, I work with just one or, at most, two windows for the code-and only when I need to see multiple code sections in parallel. In addition, I need a window where I can see the project tree and expand or collapse it. Ideally, there would also be a window that gives me an overview of the individual functions and classes in the currently displayed file, so I can quickly navigate within the file. Flexible window management is essential for me, without getting lost in too many windows.
Navigation
By navigation, I mean everything that helps me quickly get to the point in the code I currently need, and ensures I don’t see any code that isn’t relevant to me at that moment. That’s why I also consider code folding to be part of navigation.
I want to be able to jump up and down in the code tree, as well as navigate level by level. If I’m in a function, I want to be able to press a key to jump to the class header and collapse that class if I need to focus on another one. Jumps to the beginning and end of a file should go without saying. It would be great to have jumps to the point where a variable is declared. Or, in the case of programming languages with header files, to be able to jump back and forth between the file and its header file, or between the file and its associated test file-because sometimes you work on code and on the corresponding tests in parallel.
Additionally, I want to be able to navigate in the file tree, either by directly calling up the file or by using meaningful shortcuts to jump to the appropriate folders.
Editing
When it comes to editing, it’s the little things that make the workflow easier: When I type an opening bracket, a closing one should be automatically inserted. Different bracket levels should be displayed in different colors so I can immediately distinguish them visually. I’m the kind of person who uses tabs while editing-but tabs in the code are simply ugly to everyone else. That’s why it’s important that I can use tabs while editing, but they are automatically converted to spaces when saving. This needs to work flawlessly, especially in languages like Python, where indentation has semantic meaning.
Autocompletion / Intelligent Support
Autocompletion is another exciting topic. What I’ve always used is something like IntelliSense: As soon as I start typing the beginning of a variable or function I’ve already used, the full name is suggested. The key here is to have neither too many options to choose from nor to miss important ones. Precise, context-sensitive autocompletion supports me without overwhelming me.
Snippets
Here, I still dream of a universal snippet language. I want to be able to insert text blocks where I can use variables, similar to what Cookie Cutter allows. Additionally, while writing, I want to be able to create short text snippets like an if-block or a select-case block in Visual Basic-or comparable structures in other languages-using a two- or three-letter combination. Ideally, all these blocks that do the same thing in different languages would use the same abbreviation. That’s why I call it Universal Snippets. This flexibility would help me speed up my work without worrying about language-specific details.
Trial Run
The trial run is actually quite simple: I want to be able to compile and start the program from my editor-and then play around with it. Depending on the programming language, this may require some intermediate steps. These should happen automatically under the hood so I can focus on what’s essential: testing and trying out my code.
Debugging
When it comes to debugging, I’ve experienced just about everything. The most spartan way to debug is probably to insert a Beep somewhere in the program code and see if it beeps during execution. Console outputs that I write directly into the code are only slightly more comfortable. But what I really want is to be able to step through the code meaningfully: Step In, Step Over, Step Out. I also want to be able to view the status of various variables.
Setting breakpoints is essential for me-not just at fixed points in the code, but also based on expressions. For example: a breakpoint when an expression is true, or a breakpoint when the value of a variable changes. So I don’t want to stop when the value of variable a is equal to 7, but rather whenever it changes from its current value to any other value. This is something my ancient Visual Basic 6 could do, but many modern development environments lack.
It’s also important to me that I can see compiler or parser error messages directly and jump to the corresponding file and line with a click.
Testing
Nowadays, almost all modern programming languages come with an integrated testing framework. And I think that should be used. I want to be able to use these testing frameworks directly from the editor so I can run my tests quickly and efficiently. It would be great if I didn’t have to run the entire test suite every time, but could instead run just the current file and its associated tests. This way, I can work in a targeted manner without wasting unnecessary time.
Git Integration
For Git integration in Emacs, there’s Magit-do I need to say more? It just works and is solid. The only area where I’m a bit spoiled is diffing: No matter which machine I’m on, I use Beyond Compare by Scooter Software. For me, it’s the ultimate diffing tool. If I could create something comparable in Emacs, that would be amazing. I haven’t managed to do that yet, though.
A cool feature for Git integration would be if every time I save, an internal Git commit is created in the development branch I’m currently working in. Then, if I’ve saved 27 times by the end of the day and decide to keep that state, I can squash those commits and end up with a single clean commit.
Deployment
With deployment, it’s like this: Sometimes it’s part of Git integration through hooks like on GitHub. Other times, it has to be done manually. If I have to do it manually, I’d like to be able to select targets. And the whole thing should be closely integrated with Git.
Refactoring
I’ve listed refactoring separately here. Even though I sometimes do it directly while editing code, it makes more sense to sit down at regular intervals and focus solely on refactoring. When I want to restructure something, most of it is cut, paste, and rewrite. But what would help me tremendously is if I could be sure that I can search and replace variable or class names across the entire project-without the project blowing up in my face.
My Conclusion
In the end, it’s not about finding the "perfect" editor-it doesn’t exist. But it is about having an editor that supports me rather than holding me back. A tool that helps me work faster and more efficiently, without constantly having to wrestle with it. With Emacs, I have the opportunity to create exactly that kind of environment for myself.
And yes, I know I’m demanding. But if I’m going to spend eight hours a day in front of a screen, I at least want a tool that doesn’t drive me insane.
In future articles, I’d like to delve into each of these sections individually and take a close look at what solutions Emacs offers, what small functions I might be able to write myself, or where there’s still room for clever workarounds.