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.

A coworker has told me that in a previous job, he was talking to an intern and mentioned IRC and intern asked what was that. He told him that it is the “old instant messaging”, which another senior coworker overheard and chimed in that “no, IRC is the new messaging thing”.

If someone would be asking be what netbean is, I’d say “an IDE from the old generation of editors”, but I guess that is all relative :D

Why geocities of code?

kate

I use Kate – part of the KDE project ecosystem (for anyone else wondering) – on all platforms, including Windows. So worth it.

I used to use Jetbrains when I was using C# (mostly stopped now), because it was better that VS and tooling elsewhere is mediocre, on purpose by ms. But beyond that I don’t see the point. I say that as someone who has it for free through a student license. They’re such heavy editors, only kinda cross language, extension ecosystem not as good as vscode.

Great default keybindings though, I’ve adopted a lot of them elsewhere too

Do you use “home” “end” “ctrl-arrow” or any other interesting keybindings?

Same. Jetbrains makes the best IDEs hands down IMO and I say this after 20 years of coding and using numerous IDEs. I also use vscode as a backup but as more of a glorified text editor.

Haha, I know that feeling from earlier when I was trying out hx --tutor. Just staring a the keyboard trying to remember which key to press, only to press the wrong one and have it do something completely unexpected.

Hey have you tried using Vim? I like it better than Emacs

How do you debug?

In my personal experience, it’s a little faster but not a huge speed difference. However, it’s much more pleasant and ergonomic. I enjoy the act of modal editing much more than modeless.

Input speed is not “just” input speed. Note: I’m not about to argue for or against modal editors, I just want to answer: why is input speed really really really important, when (we agree) its not a big percent of total time.

5min at 80mph over a bumpy dirt path, ripping around turns is very very different than 5min of flat smooth straight driving. And not just because of effort.

A senior and junior dev could spend the same amount of time to rename a var across 15 files, move a function to a new file, comment out two blocks, comment one back in, etc. But. When I try to have a conversation while they do that, or when I change my mind and tell the junior to undo all that, its a massive emotional drain on the junior.

But effort isn’t the whole picture either: speed is a big deal because pausing a conversation/mental thought for 5 seconds while you wait to finish some typing, is incredibly disruptive/jarring to the thought-process itself. That’s how edge cases get forgotten, and business logic gets missed.

Slower input is not merely input time loss, it also creates time loss in the debugging/conceptualizing stages, and increases overall energy consumption.

If the input is already fast enough that there’s no “pauses in the conversation” then I’d agree, there’s not much benefit in increasing input speed further. BUT there’s almost always some task, like converting all local vars (but not imported methods) in a project to camel case, that are big enough to choke the conversation, even for a senior dev. So there’s not necessarily a “good enough” point because it’s more like decreasing how often the conversation gets interrupted.

That’s a good argument. The editing speed is not the limiting factor in my workflow.

Honestly, I think my interest for modal editing is a bit irrational. Maybe I don’t want to be a normie, using the default keybindings :D

I used vi for a few years so have the muscle memory and the sole advantage in my perception was that everything is simple typing with hands remaining in the home keys position (except Escape, ironically).

So it’s more relaxed if you find using modifiers onerous, but I don’t find Ctrl or Alt significantly worse than Shift, and I don’t find it any worthwhile advantage.

Modal editing for just raw text input would actually be slower, because you also enter and leave Insert Mode. I find it’s very fast and powerful for navigating around the text, which you probably do a lot more than actually editing it. And when it does come to editing, there are a lot of higher-level tools (at least in Vim) for accomplishing things more quickly, like the ‘s’ command and ‘q’ macros.

I think getting into a mental “flow” state is really valuable, and muscle memory is important for being able to stay there. If your muscle memory is to navigate around using the mouse, that’s great, but Vim feels faster to me.