Indeed. Now that I’ve said that, I’ll probably experience a wave of catastrophic failures…
My recent problems have come in the the form of “distro evolution”, where things change from release to release in Ubuntu. E.g., the hugin disappearance, home directory encryption, and now this special security category for certain softwares. Each thing has turned into a “sub-hobby” of its own to figure out…
Same here. I recently had to take a day to refactor my Emacs configuration because so much of it was deprecated. Sure, things have been piling up there for almost 20 years, but nevertheless it was a chore.
I don’t, but I think of vi users as my brothers. Users of the last other decent editor around. I have much more common with them compared to programmers who hop from one overhyped IDE to the next, until that is abandoned by the company that was backing it.
It would be a great bumper sticker: [ You’ve got vi, what else do you need? TM ]
Although I have to admit, when I was on *nix daily I used vi and <something else> in concert. vi was always there, whether on Linux, Solaris, AIX, whatever. I could use it reasonably well (if not at expert level) although I never memorized the alpha movement keys, just used arrows instead. But especially on older Solaris boxen with their old terminals it was a bit of a pain unless I spent time getting all the emulation set right. I also was off-an-on Windows every day, so I got rather attached to Geany as well. My biggest problem then were shell script that didn’t run and bad config files, because there were errant colons ( : ) scattered throughout them…
n(vi)m is wonderful to use, hard to go back once you get used to it. Recently I’ve been using Astrovim for development and has been a joy. LSP(One of the few things MS has done right of late…) has allowed almost all editors to have code completion, recommendations etc, and vi derivatives are no exception.
But I gotta hand it to the Church of Emacs and St. IGU-cius, they make a good proposition for their side.
I would be happier if I had never heard of anything built on Electron (which I believe Atom was). There’s nothing quite like a heavy browser masquerading as some other app. Unfortunately the attraction of Electron appears to be strong to managers deciding what frameworks to use (probably based on everything but actual on-topic experience, if they’re typical managers). Unfortunately the end user has to put up with the size, bloat and poor performance of the framework and the app it underlies. And unfortunately there are more than a few apps built on it, so there’s little choice.
It made sense if you were deploying your app as a web app as well, so a lot of decisions around shipping with electron were done by developers in this case. Of course this made some sense for apps like discord and the like, but for text editors? I don’t really see the benefit.
Thankfully nowadays if the developer wants to use a web framework, there’s some very lightweight alternatives that allow him to do it, like tauri.
Well, and like a lot of trendy things it became a One Size Fits All solution (i.e., one size usually fits none) in the minds of those making the decision of what to use. I can’t remember all the times we used / deployed (I was in IT) technology chosen by a manager (sometimes C-level exec) after reading some article in an airline magazine while trapped in flight…
My main complaint is that it’s just so inefficient in time and space, particularly for anything not specifically web-centric. In the case of a text editor, it would be interesting (if not outright scary) to compare a typical operation’s call stack between an Electron “edtior” and one written in straight-up C. IOW, what happens at a code level between “I press this key” and “that happens”.
One Electron app I use is Joplin, for note-taking. I understand the attraction of the baked-in HTML / Markdown capabilities, but when it comes to that whole class of apps there’s little choice in platform.
Oh, Emacs. I love it dearly. I actually did use Vim for years, and Sublime Text, and TextMate for others. But Emacs I keep coming back to.
It serves a similar purpose as Darktable for me; not necessarily the best tool out of the box, but its intense customization options make it my tool. At this point, both my Darktable and my Emacs are very idiomatic to my personal workflows. They are tools uniquely capable of molding them to my way of working, instead of having to contort myself to them. You know, the way computers should be.
Anyway, Emacs. It was there for me when I needed a git-capable terminal on a terrible old Windows box that didn’t have one. So I used eterm, (one of) Emacs’ builtin terminal emulator. It gave me something to do on the eternal commutes before mobile internet was a thing. So I read the builtin manual, and coded my first elisp, Emacs’ builtin programming language.
And it grew with me. It grew my blog generator, and my own journaling system and knowledge database. By now it is so tuned to my workflows, so as to be nigh unrecognizable (never mind usable) to others.