Work, life and other detours [II]

I don’t think length is a problem due to the nature of the game. At the end of the day it’s like reading a large book or two or three books in a series, doing it bit by bit it eventually gets done. Act 1 is slow, especially combat, but it quickly picks up pace in my opinion.

1 Like

Two years ago, I left Emacs. I was using Visual Studio at work, and had to get used to it. With disuse, my keyboard shortcuts habits started colliding between the two worlds, and pair programming was obviously impossible with it. My note-taking moved to Obsidian. In the end, there just wasn’t a good place for Emacs any more

And today, I replaced the last bit of Emacs in my daily life: my blog is now no longer rendered by org-static-blog, but a short little home-grown Python script. It was a bit embarrassing, seeing those 1K lines of Elisp replaced with 200 lines Python, and running in half a second instead of a half minute.

With that came converting all those org-mode files to markdown, which had been part of the reason for the change: You can trivially embed HTML directly into markdown, which was always cumbersome in org.

Still, I am a bit sad to see my finely-honed Emacs sitting neglected. And truth be told, I have not since found a text editor worthy of truly taking its place. While I do need Visual Studio and Visual Studio Code at work, neither are good text editors. What do you guys use?

I use neovim, vscode and of late I have been trying Zed(with vim keybinds). vscode for work(mostly .net), the rest for recreational programming where I don’t need many fancy features or use copilot.

For pure text I just use neovim. It’s fast, has a ton of plugin options and just works. I currently take my notes in markdown. The only thing missing would be a feature like in org mode where you can link stuff together. I’m sure there’s a neovim plugin for that but I just haven’t looked at it enough.

I think ultimately pure text with a few bells and whistles, aka markdown, is the way to go. Future proof even if you remove the markdown rendering, light, easy to search using simple tools, non proprietary, etc.

1 Like

On Windows, I use Notepad++ as the editor. On Linux, I don’t really do heavy editing, kate is a simple and effective choice for simple edits. I tried atom at one point, but found it to be too heavy for my simple use cases.
To work with code, I use JetBrains IDEs.

For me, it depends on what I am editing and what platform I’m on. For note-taking, etc., I use Markdown, generally with these editors:

  • Linux - GNOME Text Editor.
  • Windows - Notepad++.

For code:

  • Linux - VSCode (although I don’t love it). I used and liked Atom until support was dropped.
  • Windows - I have no code I edit on Windows. Back when I did, I used jEdit.
  • z/OS - ISPF.

Notepad++ on my Windows Surface Pro. If I go to do a quick edit on some configuration file I’ll end up using Windows Notepad, better in recent versions as it respects Unix line endings. I’ll run nano if I’m futzing around in a MSYS2 bash window for quick edits.

gedit on my Linux desktop. If I’m in a shell, I’ll use joe. I’ll use vi when setting up a buildroot system for my small devices, sometimes just until I can build a joe executable.

I use the embedded editor in OpenSCAD because, well, it’s embedded.

I summary, I use the most expedient editor at hand, never got religious about one.

Back when I was working I was typically in and out of an editor, off and on. For scripting on *nix I used Geany for all but the quickest jobs (if it was available). Otherwise I was in vi(m) for sysadmin stuff.

We had developers on Windows writing PeopleSoft code both on Windows and Solaris / Linux. I set them up with PsPad and WinSCP so they could do it all from their Windows PCs.

Even now at home I still use Geany (and PsPad occasionally) for my usually simple editing needs. I wish GTK-based apps launched faster on Windows. When I was playing with C years ago at home I liked the Code::Blocks IDE. Scintilla provides a good foundation for an editor.

vim. I want to use vi, but in my distro, vi just points to vim. That can be dealt with, but it’s too much trouble for too little gain.

neovim for everything. I slowly slid into the vim world at work, as I often have to edit files on remote machines (mostly robots, which don’t have monitor/keyboard connected) and using nano drove me crazy :D.
I think I fully switched, even on my own machine, while I worked with XC (a C variant for the XMOS architecture), which came with a horrible Eclipse-based IDE and my manager back then was pointing me to neovim.

By now, I’m at the point that it is a pain to suppress the muscle memory when writing in anything without vim mode. Most fun are tools that just close the window or delete the text without asking when you once again pressed ESC for no reason :D.

1 Like

Still emacs. There seems to be a bit of a renaissance in the last few years, and emacs can do all the modern things. There are quite a few good newish packages too, vertico, margenilia, eat, etc etc.

I have been using vs code at work, for a lot of powershell. You’d think it’d be a great ide for power shell, but its very meh. I do not understand the hype

2 Likes

I use VS Code (I work on a language server for a certain programming language and an extension). NeoVim is also pretty good.

Also looking forward to Zed becoming more fully-featured. Currently, it still lacks quite a lot of language server protocol functionality.

It provides a decent platform and base UI to build IDEs on top of.

For all of its flaws, VSC has a pretty good extension infrastructure. The extension host is a separate isolated process from the editor process and other internal VSC processes. Adding extensions generally won’t slow down your editor, at least as long as you don’t install extra naughty extensions like the Vim extension or the GitHub Pull Requests one. The extension API is a bit restrictive in some areas, but you can do quite a lot with it and it is very stable.
It’s also pretty sweet for extensions that you can easily embed web UIs in the editor.

Anecdote: I’ve built a journaling extension for Emacs, VSCode, and Sublime Text. Essentially, I just wanted a directory full of daily markdown files, and an easy way of stepping through the files.

Org-journal in Emacs was relatively straight forward. The extension API is well-documented. It’s actually not so much an API, but instead the raw guts of Emacs that you’re modifying. Regardless, it’s fun, and pretty simple, once you learn the programming language.

Sublime Text was hands down, by a very wide margin, the easiest. You just bind Python scripts to keys. Extremely simple, extremely effective.

VSCode was… I’d say “deranged”. You need to set up a build system, a project template, a manifest, and various other bits and bobs that serve no obvious purpose. The API was OK, once you got down to it. But the infrastructure, horrendously under-documented, broke multiple times for no discernable reason, was a nightmare. I very much hope I was doing something wrong (following the official docs).

I see people doing good things with VSCode’s extensions. But if this is modern web-dev, I want no part of it.

1 Like

That’s Microsoft for you… It has gotten better in recent years but when I started working, when I was doing. Net Framework, it had exactly the same issues you describe there.

The strength of vscode really is the extensions, for example: The MSSQL extension is powerful. While developing, you can select any query you want to run, press a shortcut and it executes the query against the DB and returns the output in a window. With this I rarely boot DBeaver anymore.

1 Like

Tell that to the official C# Extension… :grimacing:

It can definitely slow down your computer and thus your editor if it’s computationally expensive, but it’s usually not the case that every single plugin that hooks itself into one of the editor functionalities adds some amount of latency to core editor functionality, as is the case in the plugin architectures of most editors where you just hook yourself directly into core editor functionality.
(At least as long as you don’t have the Vim extension installed, which does something naughty that essentially single-threads all extensions with the editor. I at least haven’t yet gotten any reports of this same issue being caused by other extensions before.)

Setting up a new extension is mostly “just” the usual TypeScript summoning ritual, which I’m happy to perform if it means that I get to work in a language with static typing, even if it is a bit silly. The only thing VS Code adds on top for a minimal extension is the declarative extension configuration in the manifest.

Emacs unfortunately still doesn’t have a complete language server protocol story (unlike NeoVim).

1 Like

Interesting. I wonder if we haven’t overcomplicated things a bit in our industry. I find “suffocation in infrastructure” a common design pattern these days.

“A bit” is probably still quite the understatement, haha. The JavaScript tooling story is definitely pretty bad.

1 Like

vim is my editor and IDE for C++ development, gdb in TUI mode for debugging.

1 Like

There seems to be a fork that’s alive:

3 Likes

Emacs has its quirks, but I live with them because it allows me to integrate all things into a single interface. Eg mu4e for email, AUCTeX, all programming languages I use, and so on. I find it very convenient to work with just one interface.

But I also use vim in some environments, because it is almost always available. I understand why its fans like it.

What I mostly want from an editor is to stay the same while keeping up with technology :wink: I have a lot of muscle memory invested, so I don’t want to switch to another set of keystrokes, that would slow me down and drive me crazy.