> And it's not just the "big" things. When I want to sort a few lines in a region and immediately discover that I can just call "sort-lines", because of course I can, I know that I'm not going to bother waiting for some other editor to catch up in all those little things.
FWIW this is something most editors let you do trivially.
With VS Code, select the lines you want to sort, press Cmd-Shift-P to bring up fuzzy command search, type "sort", press enter. Your selected lines are sorted.
I think you might be surprised to find that all the major editors these days have most all of the little things you might want day-to-day covered. Of course the set of little things one cares about will differ from person to person and from the capabilities we've personally found the most use out of. It's hard to argue when that one thing you use every day isn't supported in some other editor, but the list of those is shrinking quicker than I suspect most people realize.
There are a lot of people contributing to these tools and that plus not having to reinvent every wheel from scratch (and maintain that code on top) means that modern editors can cut into the lead time advantage of something like Emacs quicker than you might otherwise think.
I think you would still be surprised at how many things emacs can still do better like undo in region or even simple macros that find use even during simple text edits.
Though ultimately feature per feature, I don't think emacs looks all that great, but the difference is that you can actually use a lot of what it has to offer whereas it's difficult to do so in more modern editors (with fuzzy matching and all).
I'm a long term emacs user and I know that my emacs use is not down simply to lock-in. I know this because a year ago I spent a month using Panic Nova to see what I might be missing with emacs.
Nova looked super pretty and it's easy to figure out how to do a lot of things out-of-the-box that's harder to figure out on emacs at first.
But there are a couple of core things about emacs that I just don't see replicated in the popular IDEs.
1. The way you manage buffers and "windows" (just partitions of the screen in your GUI window). Buffers and windows are decoupled, which will make no sense to most people if they aren't fluent in it. And these little window partitions are quickly built, re-sized, split, and destroyed at a moment's notice from the keyboard. I can and do regularly go from 1 to 12 partitions at a moment's notice. I switch buffers in partitions constantly.
I tried so hard to figure out how to not make buffer and window management suck in Nova, but to no avail. I've also done some professional development in VS Code, and it doesn't appear to be any more flexible.
Maybe someone has an extension, but I doubt it. And this is too core to my development experience to trust to something as ephemeral as an extension. And emacs has already been doing it for 30 years.
2. I use emacs in the terminal, whether on my desktop or ssh'd into AWS.
The development experience is 100% seamless. Being able to work remotely on any server with my exact same developer experience is huge for me. I don't have to have a mirror copy of the files and do any syncing between edits. I can use all the project management, file browsing, and directory searching features built into emacs with no problem. I'm always at home.
The last thing I'll mention is that, contrary to the person having doubts in the linked article, I'm not an emacs power user. Currently I use an almost-stock spacemacs install, not even in evil-mode, and I've barely explored it. The basic emacs features I learned in the first couple months of using emacs give me more than anything I've found.
I will say that if I made a whole career out of Java or .Net development, and if versatility wasn't that important, an IDE tailored to those environments would have some polish that's hard to ignore. But if I knew I was missing the foregoing, it would hurt a lot every day.
Emacs has TRAMP as well out of the box, but for some reason they want o launch a lightweight cli instance of emacs on the serverside, which VSCode can't do.
How is this different from tabs? You have global search to open files in new tabs, you can opt to leave a trail of new tabs as you follow links through your code, you create arbitrary new tabs and plop snippets in, and have an option to persist to a file whenever you wish. You can reorganize your tabs layout, create an arbitrary number of rows and columns, move tabs back and forth between different groups, splitting and merging groups as you need.
I haven't found any editor that makes handling of split panes as streamlined as Emacs, and that's because while having the tabs tied to a single document is a sensible metaphor, it's just way faster to have two or three panes whose contents you can switch from an autocompleted list of buffers. No clicking around, no squinting your eyes at the little tab titles, no dragging and dropping the tabs to switch them from pane with awkward snapping in and out.
(buffers can be files, configurations panels, terminals, applications, whatever really)
But editor ergonomics are always trumped by tool support, and Emacs' can be good, but it's never reliable in supporting environments that aren't Lisp and academic stuff like R and LaTeX.
Ah, excellent, just wanted to make sure there wasn't some magical insight i was missing out on by not being familiar with emacs.
re: clicking/squinting/dragging/animations those i would usually handle by things like keyboard shortcuts, configuring your global search to list tabs first, configuring animation.
I think what is more interesting is the idea to use the same buffers/windows for non-text-files. So, the first half is the idea of having all your tooling be text-based. There's some slider along, text driven by keyboard => gui driven by keyboard => gui driven by mouse. And then the second half of the idea seems to be how you separate text-editing/config/applications. So maybe along that slider, emacs mixes all sources / IDE groups sources within an application / separate applications for each source.
Maybe pushing everything to one edge of the slider is able to put one in a zen-like state. I guess for now I just try to find a sweet spot with my tools, where stuff i want to do fast i can do fast, and everything else is ok as is.
Every modern graphical editor I'm aware of lets you jump around in tabs/windows/panes etc. exclusively with hotkeys.
I don't know why people keeping talking about clicking around. They are all completely operable without resorting to clicking. Maybe not with IDEs, but with VS Code / Sublime / Atom, you don't need a mouse for anything I'm aware of.
The sticking point for me is that if I discover some functionality is missing, I can add it to Emacs on the fly with often just a few (1--25) lines of Lisp.
So there's several tiers to this convenience:
1. Does it do the obviously important things out of the box, or with easily installed add-ons? For most editors, this is yes.
2. Does it do the little things out of the box, or with easily installed add-ons? For some editors, this is yes.
3. If none of the above, can you create the thing you need as an add-on without breaking your step, almost as part of what you were already doing? To get to this point it takes a very dynamic system like Emacs.
I agree with what you say about IDEs, but Emacs' "advantage" over other text editors is that it is only superficially a text editor. It's really more of an operating system.
The thing with Emacs is that sort-lines is a string you can copy and paste into a buffer, whereas in Visual Studio it's a command that you have to execute.
Disclaimer: I don't know Visual Studio that well. Still, I suspect what I'm writing is true.
I find the overhead of selecting a pop up, having it appear, often then using the mouse to select something, then pressing do is just clumsy compared to the low overhead command structure of Emacs. Search is a primary cursor move operation, for example.
I don’t think I’ve ever used a mouse to operate a single function in VS Code. Literally everything (in the actually literal sense) is available through a keyboard shortcut.
FWIW this is something most editors let you do trivially.
With VS Code, select the lines you want to sort, press Cmd-Shift-P to bring up fuzzy command search, type "sort", press enter. Your selected lines are sorted.
I think you might be surprised to find that all the major editors these days have most all of the little things you might want day-to-day covered. Of course the set of little things one cares about will differ from person to person and from the capabilities we've personally found the most use out of. It's hard to argue when that one thing you use every day isn't supported in some other editor, but the list of those is shrinking quicker than I suspect most people realize.
There are a lot of people contributing to these tools and that plus not having to reinvent every wheel from scratch (and maintain that code on top) means that modern editors can cut into the lead time advantage of something like Emacs quicker than you might otherwise think.