What I Expect from an Editor as a Programmer | Plain DrOps

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...