How... Uh, how do you use computers then? Isn't everything we do with them in some way through "an app"?
I’m pretty sure they are referring to mobile/Web stuff. You do have to be very careful there…
Lazy young whippersnappers should come up with their own damn terms for new concepts in stead of just trying to co-opt and redefine existing ones.
E. g.: there was recently a post here promoting some group making “an app ecosystem for your terminal”. That’s very convenient — you immediately know you need to close the tab.
1. Missing out on "new innovations" (and using older gui/etc paradigms which don't mesh with anything else you are used to).
2. Finding ways to update your tool to take advantage of "new innovations", which costs time, and often gives you a worse outcome.
I was a vim user for 8 years, then used spacemacs for another 2, but have lately switched to VSCode (with vim mode, obviously). The ease of just downloading vscode and having it work with almost no tinkering, having it look good, and being able to, for the most part, double-click an extension name if I need it... that ease of use means that whatever learning curve I do have to pay sometimes, it's worth it.
(And the learning curve for making VSCode have the vim/emacs features I need was tiny compared to managing my vim/emacs config).
E.g. the simplest example - intellisense and inline linting, debugging etc. are all really awesome features. I've set them up once or twice with vim and emacs, but it's always a pain, always takes a long time, breaks often, etc. With VSCode, I click a button and I have everything I need for Python installed in a second.
That's the difference between actually using a feature, and not. When I install a new computer, I will actually use e.g. Python linting with VSCode, but not with vim, cause I won't bother to set it up.
For some other functionalities it is far more advance, like support for Git (magit) or very fast navigation inside the project (projectile, Helm etc), mass renaming things (grep, ag and wgrep) etc.
In general IDEs are very bad at text manipulation and good at structural manipulation, whereas Emacs is very good at text manipulation and okay at structural manipulation (or excellent for it but only for Lisp).
The set of functionalities in an IDE is fixed, whereas Emacs is extensible, by it users.
Support for git is awesome in vscode. You install a plug-in and get great support for various commands. Another plugin and you can have every line annotated with a git blame (a faded text at the end of the line), as well as having a git blame annotation at the top of each function. These were game changers for me. Though full disclosure, I haven't used magit much - but that's part of the problem. The learning curve on the vscode stuff was zero.
Project navigation is dead simple in vscode, I don't think emacs has any advantage.
As for text manipulation, as a vim snob, I'll just point out that text editing is really only good with Vim. Luckily vscode has a vim mode that's decent. Not perfect at all, but decent.
As for extensibility - all the above are plugins. It is extensible.
Vim and Emacs are console editors for me. The most significant difference for me is sensible mouse support. I used Emacs just for LaTeX, otherwise I use mostly unhacked vim. It is very useful to be familiar with one of them, but nano is awesome too and I always mention it for new developers.
I believe vscode is successful because it is simple. Just like how JSON was successful compared to XML for simple applications. It isn't better than XML, but most applications are too simple to warrant XML features and resulting complexity.
For C# I prefer VS instead of vscode and I fear vscode tries to be both, a code editor with extended features vs a fully integrated IDE. For some language like JS vscode already has become an IDE with advantages and disadvantages and it is quite often very opinionated here.
basically it seems less hackable, is that a wrong impression?
(and json files don't allow for comments right?)
That said, you can configure a lot of things you care about, e.g. you can do remappings, including complex remappings from "sequence of keys" to "sequence of keys or existing commands". And since there are lots of pre-defined commands etc, there's a lot you can do.
(BTW I mean this espeically in vim mode for vscode, I don't have experience with using vscode without it).
That being said, there is a cost. Tools that adapt with the times try to reduce the effort needed to get contemporary tasks done. Stable tools tend to reflect the times in which they were created (or at least peaked), meaning that it may take more effort to get things done in the here and now. Unfortunately, Emacs is very much a reflection of this.
Vim 8 broke this philosophy though - it changed defaults and broke workflows - changing how search works by default, breaking copy-paste by including some mouse support so when I click a line, it moves the cursor.
These aren't security improvements, these aren't transparent improvements (like allowing arrow keys as well as hjkl was way back), and they're not even odd workflows like xkcd.com/1172. Search is presumably one of the most used functions in vim, and I'm sure that clicking and highlighting text to copy into a different application isn't unusual. Changing the default behaviour is a choice that the developers made, presumably to "make vim better". I don't want vim "better", I want it stable, if I wanted "better" I'd use something that redesigns itself every 5 years.
What's worst though, is while I can adjust my workflow to automatically copy a fixed .vimrc onto any machine I ssh to, it leaves me wondering "what will change next". It's unsettling.
But there's literally nothing I don't have with Emacs that other editors provide. I have code completion in a bunch of languages (that pops up, with documentation pop-ups), linting, snippets, a project tree preview, project awareness, etc...
Hmm, refactoring, fixes of Flycheck errors (if the checker/LSP provides them), a Tramp mode that actually works.
Oh, and I would like to be able to continue editing my file while Emacs is doing something else ;)
Emacs hanging at times has unfortunately been the reality for a looong time. There is extensive async support, but it is not always used were needed.
I used (the paid version of) Xrefactory a long time ago with Emacs and C++, that really worked well.
The Clojure-LSp has many code actions too.
> Emacs hanging at times has unfortunately been the reality for a looong time.
Well, at least 25 years :D
I like Emacs, have an extensive personalised config and use it as my primary editor across OSes.
That said, I wish its debugging-support was better. Some simpler “just click to start debugging” options for a few popular platforms would be nice (Node, Python, .NET, Rust, whatever).
I’ve heard there are similar efforts like LSP, except for debugging. Maybe they can help out Emacs’ debugging-support, just like LSP helped improve Emacs’ auto-completion and refactoring support?
Until you use a plugin which is dead after the next update. Which happens a lot...
> Emacs lisp is more intuitive than JSON files
Not really. In the first place JSON is just data-format which usually is used through a proper GUI. There is not much you can do break there.
> But there's literally nothing I don't have with Emacs that other editors provide.
Which only means your horizon is too small to know the missing parts. Or your work is not specific enough to demand something not available in emacs.
If you are satisfied with emacs, ok. Good for you. But how will it benefit the popularity of emacs?
Not even comparable. The functionality VSC misses you can get with installing some extension, which works out of the box, with hardly any configuration, and with a very simple way to find, select, install, enable, and disable it.
>However that setup is saved forever, across machines in the form of your .emacs file
Even that's something you need to do manually in Emaca. In VSCode it's automagically synced to GitHub, and indeed is "saved forever, across machines" -- and with smart ways to handle conflicts and such if you change it elsewhere, etc.
>And it's really not much more difficult to setup, Emacs lisp is more intuitive than JSON files
VS Code has a graphical UI that abstracts away the JSON configuration files, provides autocomplete of options, limits you to available enumerated options, picks up automatically the proper UI for the config of an extension, and so on.
And even when if you want to edit the raw JSON to change the configuration, it's of course vastly easier than Lisp (a full programming language), plus it also has autocomplete for key names and values, and so on.
Also, saying EMacs Lisp is more intuitive than JSON is quite absurd. You could give a 15 minute presentation on how to read JSON to someone who knows how to use Word and they’d at least be able to read it. The same wouldn’t be possible with any subset of lisp.
If all you're doing is serializing the configuration, then lisp's s-expressions are just as intuitive as JSON (in the sense that both can be explained in a few minutes).
Also, the argument that lisp's s-expressions are just as intuitive as JSON is verifiably false because you can use a simple natural experiment: what is used more for serialization, JSON or s-expressions?
It's extremely ironic to try and argue these points on a post that's entire theme is how to get more people to use an editor that is quickly losing market share to easier to understand and configure applications.
Some new thing is intuitive to a certain person, not everyone, if and only if that person has previously developed some intuition --- tacit experience --- that translates to that new thing. So intuitiveness is more a function of the previous experiences of a person than of a thing itself.
Whereas intuitiveness for an average member of the target population of a product is a useful quality of that product, it is by no means the most important quality of that product. Or else the most "intuitive" products should never introduce any changes, shouldn't they?
The syntax of something is only one part of its intuitiveness. A large part is the context of which it is used.
Some IDEs that can semi-compile the code (to something like an AST) can provide a lot more support for refactoring correctly.
Plenty of Emacs plugins invoke a compiler, language server, whatever to get information about the code. That isn't a feature unique to IDEs.
Yes, but Emacs (at least the LSP-modes of the languages I use) doesn't offer the same refactorings and code fixes like the same LSPs do with e.g. Code.
Treesitter doesn't work with many languages, so syntax highlighting is also lacking for many languages.
Foo f1 = ...;
Foo f2 = ...;
Bar b = ...;
std::cout << f1.name;
There may still be some gap with some very advanced integrated IDE support, but the LSP ecosystem is still evolving and getting there. Which is not a surprise as Microsoft designed it for VS Code. The difference now is not so much between an IDE and a given editor, but between and IDE built-in language support and LSP servers for a given language. For C/C++ the progress of clangd is real over a few years, and it's very usable now.
Other editors save you play time you need to spend with emacs to get it to anywhere close to usable.
1) Most students already basically know their OS's graphical interface -- the "basic keys" like cut/copy/paste/load/save all work as expected.
2) The first time you load many common filetypes (like Java for example), a box pops up saying "Do you want me to install a nice set of standard Java plugins?"
Both points are really useful for getting started quickly, but would I imagine be really hard for emacs. The first would require changing default behaviour on first startup, the second would need accepting some set of people to decide the "default" sets of plugins.
For those who say "emacs is worth learning", that might be true, but when students can choose between Emacs, Vim, VSCode, nano, Intellij, pycharm, Eclipse, Atom, Sublime Text or Notepad++ (that's all the editors I think I've seen in the last year), they need a special reason to give emacs all that extra work needed to understand it.
Vim/Neovim had a bump a few years ago and got really popular (although that might be over now, at least on my limited experience). I think that was because there were obvious improvements going on, which attracted students to take a look.
This. Used Emacs for fifteen years professionally, and I gave up when I had to reinstall my laptop, as having intellisense-like features and easy navigation in Emacs is a complete pain.
I actually did not intent to switch to VSCode, but after a couple of hours of scratching my head with list configuration files, I ended up "trying" VSCode, and after a couple of _minutes_, everything was working (completion, navigation etc.)
After a couple of tweaking, clangd was plugged, and I had direct visual compiler feedback in realtime while typing code in the window.
VSCode is not "better". It's just another world.
Spacemacs does this, which is the main nice thing about it. Unfortunately, it also carries a lot of other baggage rather than just doing this.
It comes with very few extra packages installed, but when you try to open a file in a certain language, it will offer to install a set of "standard" packages for you that enable support for it.
Wall time, not fuzzy memories à la "it takes 5 minutes to cook this".
My bet? Tens, if not hundreds of hours.
EDIT: For comparison, I've probably spent 100x that (if not more) on Linux configurations.
And there isn't enough time in the world to become as proficient as I'd like for those, let alone if I'd waste time to optimize tools to get 99.999% efficiency with them.
At some point your hammer is good enough and your saw is sharp enough.
Well that's great but none of that gets anything done. You need to be able to write programs effectively.
> At some point your hammer is good enough and your saw is sharp enough.
Yeah. I don't regularly invest many hours into emacs. You asked how many hours went into it. Over the past 15 years it's countless hours. Over the past year, not many at all.
:-)) Of course it does. Most of my time isn't spent in actually writing the programs. It's in reading and understanding what they do, how to best modify them, debugging issues, etc.
I'd guess I spend about 10% of my time, at most, actually editing characters.
BUT the big difference is that the decades old portions of my .emacs are still very relevant and in use every day while basically all the work I've sunk into configuring some long forgotten GUI junk has rotted away long ago and has to be redone over and over again.
We all spend an enormous amount of time tinkering with things but unlike Emacs most of it is so ephemeral that it's forgotten the next day.
total time invested over 40 years - less than 4 hours.
The last time I had any reason to consider getting into emacs, was when I came across a proof assistant many years ago that basically required it - it used emacs to provide an interactive interface. Not unlike how everyone uses electron/chrome these days to quickly provide a familiar interactive interface. It was like an exotic artefact from a parallel universe where emacs' conventions became dominant instead of IBM and Microsoft's.
Also love the VS Code vim plug-in.
Emacs as an editor does take effort to learn, and it's a different type of effort from all the other editors you mention, because they are all quite different beasts.
In the end, it comes down to pedagogical considerations and how each individual learns.
Emacs has suffered by having an awfully austere default installation, and Linux distributions have refrained from delivering a version with something like Doom or Prelude to make it more approachable. (Prelude is my favourite.)
Other schools make a point (or made, not sure the current state) of changing languages between courses in the first couple years and giving more choice to students later. Like, an OO course would have been taught with Smalltalk after an intro algorithms/data structures course sequence using Java, Python, or other languages. A compilers course may have used SML, but it wasn't an SML course, just a compilers course that happened to use SML.
 The most I've seen, it was absurdly paced, an intern was taking that one.
Spacemacs also does this, and it's a big part of why I stuck around long enough to discover some of the plugins that make the Emacs world really special, like Org mode and Magit.
I'm still no Emacs hacker, but I know enough to get by, and that a good starter kit can make me productive in Emacs in just a few minutes.
Though one day I will bother to configure emacs from scratch, but that day is not today.
I actually don't think these are very hard from a technical perspective.
The first has been done in the past. Aquamacs was a version of Emacs for Mac OS that supported conventional Mac keyboard shortcuts, in addition to the Emacs ones.
The second should really just be a matter of matching certain file extensions and prompting to download the most popular mode for that file type. The Emacs package manager is very good, so it's a simple change to just include a mapping from file extension to Emacs package and trigger the prompt when opening a file of a given type for the first time.
And Emacs choose perfectly good, perfectly sensible defaults on all these things back when it came. (That can't be said about all editors from that time.)
It's just that in the 30+ years since, the world has converged on other defaults. Every little thing is done different than you're almost certainly used to - yet not different enough that anyone can claim it's somehow superior (unlike its modal cousins from the same period. I think their claim is dead wrong, but at least it's different enough that they can persuade some).
What is Emacs really? It's a virtual Lisp machine with a standard library for writing graphical text applications. It's more like the JVM than like Notepad.
It just happens to come bundled with a text editor (and a file manager, and a calculator, etc) as example applications. You're free to install a better text editor than the bundled example, and many people to (see the popularity of Evil, for example).
But of course, this is a much more complicated point in space to sit in, so Emacs markets itself primarily as a text editor and we get confusion like yours as a result.
... Although, now that I think about it, being told this mind-blowing revelation about the emacs nature might have confused me even more.
What I love about emacs is that I have a variety - an extensible variety! - of programs under one roof, so to speak, sharing the same - customizable! - keyboard shortcuts that comfortably integrate with each other.
I think the main problem in "proselytizing" emacs to potential new users is that it is kind of the C++ of text editors, in the sense that it takes a very big up front investment that does pay off in a big way if you persist, but getting to that point took - at least for me - a multi-year commitment. It is hard to sell someone on that unless they want to do it anyway. I did it out of fun and curiosity, but if you view it as an investment in purely transactional terms, it's hard to sell.
I cannot blame you. And if vi makes you happy, I want you to enjoy the heck out of it. Between discovering emacs and making it my editor of choice I spent a few years using vi heavily, and to this day, I reflexively use it for quickly editing config files.
Regarding emacs, all I can say is that, in my experience, it gets better if you really stick with it for a while. The payoff is huge if you put in the time. But time is limited resource, vi gives you a payoff much faster, so ... like I said, if it works you, don't fix what ain't broken.
I love Emacs, but I also love the variety of editors programmers can choose from. With programmers' editors, as with society as a whole, I consider diversity an advantage.
My impression -- obviously as an outsider! -- is that Emacs' immense flexibility comes at the cost of providing a lot more surface area for packages to get in one another's way. When that happens, you need to be willing and able to untangle things -- and while each individual tangle is rarely a big ask, they can add up, especially when you're coming from VSCode or Sublime Text or what have you.
So now there's a product that leverages the architectural advantages of Emacs, with modern defaults across the board.
(A non-Emacs user might very well go "Emacs plugins can do what now?" at the description of a plugin re-defining a core function. That's a fully understandable reaction. That level of hackability is not for everyone. But as far as I can tell, it's unique to Emacs and very small set of other software.)
But I could be misunderstanding this. Maybe VS Code actually does have Emacs-level hackability, in which case I'd probably want to try it out more than I have!
Of course, you're not supposed to do it other than very carefully and it has caused me problems when some plugin has made a mistake in a way that worked for the original author but not for me, but because of the openness of the system, it's fairly easy to "overwrite it back" automatically when the plugin is loaded – and submit a patch back upstream.
So maybe this sort of system works only when a large portion of the users are hackers, and making Emacs more popular is not a good idea!
Of course, if one does learn how to modify vscode, one has a skill (namely, web dev) in much higher demand on the labor market than knowledge of Emacs Lisp.
however VSCode presents an API around a specific notion of what a language is and how it interacts with the editor. emacs comes in at lower level and presents a model with just buffers and text.
I remember elisp debugging as being a joy - not really finding that to be true. but I really don't want to be limited by what the VSC designers thought I should want to do with source files - actually I don't want to use source files at all.
I would say Emacs has this as well, in its syntax tables. They are its schema for "what a language can be" and especially "how the editor can interact with it".
If you're on something as radical as not using source code to describe a program (what are you using then? A DB of some sort?), I don't think either emacs or vscode can be your tool of choice.
We know there's no free lunch, if an extensible development environment was flexible enough to make this sort of thing easier, something else had to be made harder.
For the most part, except for the fact VSCode is owned by MS and has just enough proprietary code to break a lot of functionality if you try to use it without the proprietary bits.
That's a personal policy choice, not a technical concern.
Being a Lisp machine is core to the value of Emacs. Emacs-without-Lisp is just another editor.
Yeah, it's a super joy to write.
Makes it really hard to take anything you say seriously when you reveal just how ok with extreme hyperbole you are
FWIW, when I hear people talk about VS Code, they appear to like it very much. But AFAICT, it has some way to go to catch up with all the functionality emacs has accreted over 30+ years.
It was actually started in 2000 and doesn't seem to have progressed since 2014: https://emacsninja.com/posts/state-of-emacs-lisp-on-guile.ht...
Plus, even if it's finished, will it get any traction in the ecosystem? Will the ecosystem start moving to it to take advantage of its unique benefits? Who knows?
Bonus: Have you heard of GNU Hurd? :-)
The trouble with Hurd, IMHO, is that I've run out of jokes. We used to joke that it would run Duke Nukem Forever out of the box, but that one actually got finished. Then it was Perl 6, but that has arrived, too. Star Citizen maybe?
Of course I'm familiar with the "never leave emacs" meme, moon phase indicators and "what it needs is a good editor" etc. I even gave an example of it being used as a platform in my other comment here (proof general).
But this was about its popularity relative to other editors, not relative to other scriptable framework things.
Well then in that case, ship a better Lisp than emacs lisp?
- magit :: everyday things are just a key away, less common things are visible, complex things are possible
- Org-mode :: whole life in plain text (for some brain types it enables almost impossible to achieve otherwise
I can do things no other would let me do easily. Namely: create automatic exams with latex, each for a different address and send each to its corresponding pupil, all in a single script.
Attaching is a breeze, by the way.
Well, Ctrl-_ is three keys; control, shift and _. However, Undo in Emacs is actually designed to be on the two-key combination Ctrl-/ and the fact that this key produces the same ASCII control code as Ctrl-_ is incidental.
(global-unset-key [(control z)])
But the nature of the editor is customization like this. People unwilling to do this just aren't ever going to be happy with emacs. And for those just learning, tricks like that (c.f. emacswiki.org) are a very reasonable entryway into a world of possibilities.
I mean, look, Emacs isn't ever going to be VSCode. If you want VSCode, use VSCode. It's a great editor, and frankly at this stage I think nothing is going to do VSCode better than VSCode already has. Emacs is something different, and we might as well embrace that.
(Not that I'd object to switching some of the dumb defaults around, of course. I just don't think that's going to help very much if your goal is "displace VSCode").
Shipping with some easily configurable presets to mimic other popular tools would probably help new users a lot.
(global-unset-key (kbd "C-z")))
(global-unset-key (kbd "C-z")))
Would I submit my choices as good defaults for new emacs users? Hell no. But they remain good choices nonetheless. That's the essence of my point, not the minutiae.
1) I don't have to worry about finding free bindings under C-x, C-c, or at the top level. Those spaces are pretty crowded with out-of-the-box bindings.
2) C-z C-h automatically gives me a nice list of my custom bindings.
(For the very rare times when I actually want to suspend Emacs in a terminal, I don't mind typing out M-x suspend-emacs RET.)
(global-set-key (kbd "C-z") 'undo))
Of course, no context switching is needed if you do everything in Emacs.
People trying to learn very deep kind of software should be ready to swallow a little more info than that IMO.
Out of genuinely interest, what claims specifically are you addressing here and why do you think are they wrong?
That Emacs lets you design a great user interface is exactly why some people want to “live in Emacs”. (Similar to how some misguided souls prefer to “live in the terminal”...)
I used to dedicate a couple days every January to investigate new emacs tools. Read about the latest features or new modes, often from my org-mode TODO list where I bookmarked them. I have learned to never update emacs mid-project as I've on multiple occasions shattered my emacs config updating versions or moving to a new distros. MacOS brew install vs .dmg install? Aquaemacs? DoomEmacs? Oh, hello the malpa repo URL changed and is https only now.
"eldoc" error wrong-type-argument stringp number-or-marker-p
Googling that doesn't get you anywhere.
VSCode has a healthy extension marketplace, something emacs should adopt.
elisp is dead. Not because it is dead, or deserves to be dead, but because everyone "believes" it dead. Same goes for Perl.
I love emacs, it has been a rock my entire programming life, but it's a time suck to configure. I know there are some who have created a Sistine Chapel in their .emacs.d, and I'm jealous. There's a fine balance between spending time and effort optimizing and sharpening your tools and emacs is deep on the wrong side of the line for me.
I don't want emacs to ever die. But come on, if you're losing to vim in popularity, you are already dead.
I’m not sure it was ever alive to begin with. Not in the classical sense. I mean, I don’t think elisp ever got good (or any) use outside of emacs configuration and extension. There weren’t any popular web frameworks, numerical libraries etc. written in elisp.
Inside its target space, though, it seems as vibrant as ever. New, helpful packages keep appearing that are written in elisp. For better or worse, the extension ecosystem is not nearly as fragmented as some other editors.
That’s not to say that elisp doesn’t need serious improvements, though. Making it natively multi threaded alone will advance the story quite a bit imo.
What’s wrong with MELPA?
Common mistake. The problem is procrastination and bike shedding, not emacs. It’s because some people love their tools, sometimes more than the craft.
It’s the same with cars, photography and woodworking.
Maybe because hacking emacs lisp, supercharging a Miata, retro-fitting lenses or Tuning a pre-war Stanley handplane feels as good as using them.
This week I did with Python what I used to generally do with Perl. Write big throwaway programs, written quickly. I realise this was possible because Python has been heavily Perlified over time.
That way we just managed to write Perl in Python, by converting Python to Perl.
Python is Perl 6.
I guess I'm a necromancer.
I'm ok with this.
I wonder if it's possible to move on from elisp. Create a EMACS 2. Maybe with Scheme. Maybe a language neutral extension system/API? (So you can use whatever language you want.)
Maybe it's easier to understand via analogy. Let's consider cars. Of the global population of car users, relatively few of them are F1 racecar drivers. Furthermore, you can easily make the case that the particular features (aerodynamics, speed etc.) that make the F1 a good racecar, would not be useful for the average driver - the time they spend honing their skills to handle such a beast, you could argue, would be better spent on other things. But, at the same time, the F1 car has and will continue to have a place in the car ecosystem.
In the case of developers, you might be right that, for the average developer, working on your run of the mill, mundane, forgotten-in-a-few-years, CRUD web apps, a normal _average_ car (M$ vscode) would be a better investment, but no matter what, you will never be as fast or flexible as an F1 car (GNU Emacs).
Being able to drive an F1 car comes with excellent financial opportunities. Even if I'm not "on the grid" (i.e., actively competing in the GPs), I can be a test driver. Heck the license required to drive an F1 car opens other doors in itself (maybe in other motorsports, but also allegedly the range of vehicles you can drive).
In contrast, if I am proficient in emacs I am...proficient in emacs. I edit code in a manner that is visually impressive to maybe three persons in the CS department. I'd have an ever-so-slightly deeper connection to RMS than your average CRUD-slinger. I am out of advantages to enumerate and I'm trying very hard.
Maybe text editors are about as similar to cars as apples are to buildings.
Actually, vim is not a very good implementation of vi's principles.
Concerning Emacs, as a heavy user I think it needs 4 things to stay relatively popular. I don't think it will be ever super popular, and that's fine:
* Get popular workflows to work with zero configuration. Some packages like AuCTeX, Magit or Notmuch are great at this. But many programming modes require adding too much code to init.el (or .emacs), this code breaks often and it is poorly documented.
* There are too many half-finished packages for some tasks, mostly programming modes. Variety is great, but too much fragmentation is hurting the ecosystem.
* Look at things that other editors are doing better, mostly VS Code. In the past, this approach motivated implementing a package manager (ELPA), which was a huge step forward.
* Get better documentation. It's hard to find up-to-date information for many packages. Besides, the tutorial focuses too much on keybindings and doesn't talk about Emacs core principles. So, to a beginner Emacs looks like a bunch of keystroke tricks that make zero sense.
Vim can be upgraded to IDE with plugins, and Emacs can be downgrade to a plain text editor, so they are comparable, but their primary goals are different: Vim focus is on editing of text, while Emacs focus is on integration of editor with tools.
If you need a development environment, then forget about Vim, JEdit, nano, pico, etc. If you need just a text editor, then forget about Emacs, Eclipse, Idea, VSCode, etc.
The Vim vs. Emacs “war” meme has far surpassed the supposed rivalry itself; the two programs are so different that you might as well be comparing a, I dunno, a megaphone to a woodchipper. (What, the analogy doesn’t make sense, you say? Well exactly.)
The two programs attract not only people with different temperaments but also people with completely different needs and wants.
F1 race cars are literally the least flexible cars available. They are designed for exactly one type of racing and there is hardly anything you are allowed to configure the way you want. There are cars with higher top speeds than F1 cars, and cars that accelerate faster. A $2k second hand Honda Civic will beat the crap out of an F1 car around a gravel track. F1 cars aren't even the fastest design for racing on F1 race tracks. F1 cars are only good for one thing, and that is winning F1 races.
How about in the snow? How about a road with random 2-inch-high debris? How about a road with lanes of uneven pavement? And how's that air conditioning in the F1? Great for transporting kids too.
The F1 is designed to do exactly one thing exceptionally well, at the expense of practically everything else. It is the opposite of flexible.
And none of that will matter after the first time you drive over a 6 inch rock
Well, I can't say that I like cars or enjoy driving them, but the biggest advantage of a car compared to a bike is its roof - at least, when it rains.
I found this a bit confusing. Why is that, do F1 races have a speed limit? I openly admit my ignorance about F1.
The "Formula" in "Formula 1" means there are certain constraints (i.e., the formula) to how you can design your car. Very quick illustration, check out the buzz on the new F1 car spec for next year. It is already touted to be faster than this year's cars mostly because of aero changes.
Even easier illustration: the current (and I assume all future) spec has this halo whose sole purpose is to protect the driver. It's a ~7kg frame that's basically dead weight to the car. You can remove that and instantly gain maybe a few seconds of laptime at the expense of safety (I am in favor of the halo's presence, btw.).
The spec aside, the rules and regulations also try to enforce a competitive line-up so they regulate budget and, next year, wind tunnel testing time. So in theory if teams had carte blanche for car R&D we can have faster cars. But they won't be F1-compliant so they lose by default.
F1 cars are mostly optimised for massive aerodynamic downforce and lightness, which allows for unholy levels of braking, acceleration, and cornering speeds, but eventually the downforce hobbles top speed.
The LMP (Le Mans) formula of a couple of years ago has heavier cars with higher peak outputs, but lower downforce. They're slower around an F1 style track because their cornering and acceleration suffers due to the extra weight, but they have a higher top speed if they're on a long straight.
Your analogy works too, but it's parallel.
In reality though, Emacs is a subpar editor for both everyday and specialized tasks that's fallen into obscurity as its maintainers refuse to implement anything that would make it keep up the pace with superior editors.
Until your Emacs process is hung again, waiting for IO, or can't process a "jump to definition", or chokes on a file with extremely long lines, or the stitched-together macOS dark mode switcher daemon has crashed, ad infinitum.
Yes, it's a race car, but from 1987, and in total disrepair.
The massive flaw in your analogy being that Emacs has more to do with an old and crumbling collection racing car than a F1. Its users constantly need to tinker it to make it somewhat run like a normal car. It’s still slower and less ergonomic but they are blinded by their love and habit to its obvious flaws.
The amount of IDE and editors that just work well with little customisation and have great refactoring features is now so high, it leaves little place for emacs.
What can they do that emacs can't?
They realize that despite the potentially subpar text editing experience, a highly polished modern Integrated Development Environment is a power tool and a productivity machine for the environment it's aimed at.
One simple example, maybe Emacs can do this. Can Emacs through a press of a button, show a tooltip or a hovering window, directly over the text where my cursor is? Not another window to the side of the editing window or below it. I want my eyes to be stationary and I want the tooltip to be easily dismissable.
Plus, IDEs have professional developers writing integrations so I don't have to, and they're paid to do that for tens of thousands of paying customers, so they pretty much are guaranteed to work. They are also pretty much guaranteed to work well with other advanced integrated features.
2. Why would I want to put a tooltip over an emacs window?
3. The things that contemporary IDEs can do that Emacs may be clunkier at are mostly things I'm not interested in doing. They are also often addressable in totally different ways. The speed of tools like ag(1) and their integration into Emacs changes the need for Emacs itself to be able to take me to special places in a codebase, for example.
Why would you want to? I don't know.
But <<I>>'d want to :-)
Let me check...
Yes, it can do it. In org mode at least.
I have spent way more time fighting against the VS Code configuration than I would like, and even comparing it against all the time I've spent customizing Emacs over my lifetime, I don't think VS Code can come out ahead. All this because I'm not building my project with some build system that has a simple, easy integration with the IDE. When VS Code instantly works, it's great. Otherwise, I'm editing JSON configuration files. That doesn't seem like some massive improvement over editing your .emacs file. It's often worse.
Emacs is my escape hatch for "damn, VS Code is messed up again, and I just want to work on the code instead of fussing about". I've had major problems getting VS Code to deal with the C or C++ code that I work on, like, at all. I'm hesitant to even try CLion because it sounds like many of the problems are the same there (it has great CMake integration... but I don't use CMake).
> One simple example, maybe Emacs can do this. Can Emacs through a press of a button, show a tooltip or a hovering window, directly over the text where my cursor is?
That's how code completion works in Emacs. Integrates with LSP, if you want, with various fallbacks.
LSP has really leveled the playing field between IDEs and Emacs. It lets you get a lot of the high-quality integrations, and they work well in both Emacs and IDEs. Prior to LSP, I'm going to say that the only easy way to get that kind of tooling was to use an IDE for a specific language, and it only worked well if your build system was integrated with that IDE.
> Plus, IDEs have professional developers writing integrations so I don't have to, and they're paid to do that for tens of thousands of paying customers, so they pretty much are guaranteed to work. They are also pretty much guaranteed to work well with other advanced integrated features.
My experience with C++ mode in VS Code is extremely rough.
This is the age-old problem... I remember reading people making the same complaints about IDEs and text editors on newsgroups in the 1990s. Like, if you are a Mac programmer, you want to use CodeWarrior... if it works. If you have a more complicated build system, then you need MPW. Too bad.
The experience with IDEs is getting better, much better, and I think all that is really happening is that Emacs users occasionally pop their heads over to IDE-land to see if will work for them. Sometimes it does, and you get one of those articles you're talking about.
That's because you're supposed to use Visual Studio for everything VS can do at all.
I'm fairly familiar with it, and how it's integrated with MSBuild, and what the limitations of MSBuild are, and whether I'm comfortable working within those limitations (and porting my code to Windows).
It's flexible to cover maybe 90-95% of development needs for the main language targeted.
And for those clearly defined use cases, modern IDEs generally fly. Which is far from guaranteed with bespoke configurations (Emacs, Vim).
VS Code has a ton of language plugins you can use all at the same time.
IntelliJ has a ton of language plugins you can also use all at the same time.
No, they don't. Show me the IDEs with Common Lisp, Coq, Ocaml, Haskell, Elm, ... support.
That's actually the reason Code is a real alternative to Emacs and Intellij isn't.
Emacs shines when using Coq (with Proof General) or Common Lisp or Clojurescript (I guess Clojure too).
But for mainstream languages like JS, Go or Python you're better off with something like Code.
And there are roughly 20 F1 drivers on the planet at a given time, are you suggesting the total audience for emacs is about 20?
Some of us want a car that any of our relatives can just jump in and use.
Both goals make sense.
Yes, the Jeep Wrangler will topple over while trying to go through a ravine (which no other mass-produced four-wheeled vehicle would ever be capable of going through), but that's what after-market rollcages are for.
An F1-analogue editor would be incredibly fragile, narrowly focused, and demand a huge amount of maintenance.
For the last, both this HN discussion and IIRC TFA offer widely varying estimates as to how much people need to tinker with their configuration files. For the others, only being able to run on one kind of track (absolutely flat ones) would be for an editor to only work for one programming language; spinning and flying into bits at the slightest touch would be for the editor to crash as soon as you type in bad syntax or misspell a variable name; and needing the engine rebuilt after each race and replaced every third or fourth would be... I'm not sure, needing to update to a new version of your editor every three or four weeks?
If Emacs is like any sort of car, it's certainly not an F1 one.
If we want to assign a car to emacs, it's more like a Toyota Tacoma, with no body. Rugged, flexible, some basic building blocks that function out of the box.
So going by results, if emacs was so awesome and if it gave such a huge boost, then we would see those results, and it would be trivial to convince anyone to switch to it.
Personally, I don't see editing text as a bottleneck for developer productivity. The vast majority of time is spent reading code, thinking about code, stepping through/debugging code, reading specs, etc. Yes, emacs can do those things to (as can any system that supports plugins), but my point is that we don't see a 'competitive edge' where all the most productive developers use X. What we see is productive developers using a wide variety of tools. Going back to your F1 analogy, there isn't a single sedan winning F1 races.
Rather than an F1 race car, maybe the analogy would be better made to one of those backhoe/front loader combos. While it won't do simple operations like getting you from point 'A' to point 'B' as quickly, you can do more once you get there as compared to the family sedan. Of course, once you do get there you have to invest substantial time learning how to use the backhoe, the front loader, how not to tip it over, how not to inadvertently break stuff with it, etc. But once you've taken all that time and practiced it enough... you can do quite a lot.
That metaphor feels very much more Emacs like.
With regards to obsolete and outdated - I started using vi and emacs back in 1989 (I currently use vi more). The keybindings and such I learned back then are still relevant.
In my day job, I mostly program Android. Before 2014, I programmed with Eclipse and an Android plugin, which is what Google suggested. Then Android Studio was released, which is what Google suggested. As I haven't used Eclipse at all since around 2014-2015, Eclipse, to me any how, has become "obsolete/outdated". Yet I'm still using vi (and emacs) as I have since the 1980s. They have not become outdated, I still use them as I always have.
Most people want a newer car, that's picked up the improvements in safety and performance from the last 30 years.
The greatest threat to Emacs, as to any other fairly well-liked open-source editor, is a paradigm change in how software gets built or run, not whether it has 7% or 9% mindshare.
The modern paradigm of running npm/brew/composer/webpack/whatever gimcrack tool that gets shoehorned into the build process has led a lot of people to the VSCode-ish side of things that make integrating these things easy. emacs tends to look like a well-appointed workshop with lots of good, sharp tools and a stack of raw lumber, whereas VSCode looks like a finished Chesterfield. It takes a certain sort of person to prefer the workshop over the finished piece, and I'm not sure you could ever change that.
> The greatest threat to Emacs, [..] is a paradigm change in how software gets built or run
Is a little to far into scify land.
First it requires software to no longer be text based, and then it requires virtually all software to switch to this non-text based solution.
In that world a single user can keep Emacs up to date and compatible by asking our AI overlords to do it.
First, Emacs has the best Vim compatibility I've seen outside of Vim itself. Visual Studio is probably "good enough" for me on this with the vim plugin, but that 5% difference in compatibility makes a difference in practice.
But the largest reason I can't get away from Emacs is Ivy/Counsel. Being able to fuzzy search on the current file or entire project, see results, jump around to each one to see context, make changes to the results in an occur buffer to selectively mass edit search results...all of that I just haven't found a replacement for. Search/replace just doesn't cut it.
So effectively if I move to another editor, my code navigation time increases by 5-10x. Things like better autocomplete might fill that gap, but just even understanding how things go together is so much more difficult when you're fighting with your editor.
Add on other things like org-roam, buffer fuzzy searching in Ivy, fasd tie-in, the customization options, etc, and Emacs is just an amazing experience. There are definitely things I would change, like inline debugging (which I use VS Code for instead), setting up languages and autocomplete, etc. Getting things just right takes a long time for a new language.
Lua as the default configuration language makes things simple to configure as well.
Having said all that...if someone told me [insert-text-editor] had everything I would want I would probably check it out and go home to vim (but I do enjoy learning about new stuff and features).
 https://www.youtube.com/watch?v=65AVwHZflsU -- demo video
Some other editor is more popular now, and in five years, something else will be more popular than that. Meanwhile, Emacs will continue to grow, fascinating new users and developers.
Simply put, (eq 'new 'best) doesn't evaluate to true. Knowing your way around Emacs says something about you as a programmer or computer user. Like you are clearly curious, willing to learn, know some Lisp, read documentation and recognize possibilities and depth when you encounter them. Knowing editor XXXXXX usually says nothing.
Oddly enough I don't use it for code editing as much as I do for reading (TAGS navigation is great!)
But, for a lisp environment - it's outstanding! I use it to do complex Jira queries (jiralib2), and have even used the source to jiralib2 as inspiration for writing my own RESTful connectivity to two other proprietary in-house systems.
Then I cross reference them, to find out what stuff needs my attention immediately. There's no amount of email notifications, or slack bot popups that can replace what I'm doing for my workflows every day that I can get done in Emacs right now.
Basically I create a lisp-interaction mode document, and treat my lisp expressions like things I can expand in a report by C-j'ing them. Then I've got keyboard shortcuts to open things in brower tabs using eww's functionality.
I did a demo video for a few coworkers and folks who'd strayed from Emacs are starting to think about coming back to it again.
I started kicking around the idea of building this out again in Racket, just to learn Racket, but it's a distraction from the system that's working great for me right now.
My compile, test, edit cycle is now driven mostly by the Acme editor which makes it easy for me to script connecting to remote systems, issue builds, find failures, and jump to the line of code where things break while I'm working. I haven't found a way to go faster than this.
Perhaps VS Code could replace some of this, but I just don't have the time (or perhaps the gumption) to give it a try honestly. Maybe I'm just having too much fun...
Not only do I have virtually the same, infinitely configurable interface for coding in any language, I also have that interface for most things I need to do in my workday. On top of coding in my day-to-day I:
- manage my task lists
- manage clients and projects
- keep a daily journal and other notes
- draft documents and create templates
- search through or replace in multiple documents
- navigate directories and manage files
- do quick calculations and tables
- and much more
All using the same interface, without having to reach for a mouse or switch to a different program. The amount of cognitive load and context switching this reduces is great.
The only other tool I use that is as flexible is the web browser, but it's nowhere near as consistent.
Of course it's emacs, so if I chose to I could also manage emails, newslists, blogposts, pong, etc. etc.
If I'm playing with a language that is much better served by an IDE or vscode, then I can always use it for that language. However I find that a) those features that made me want to switch weren't worth losing the other powers and I eventually end up back in emacs; and b) often the language's emacs package will eventually end up with that feature anyway.
It is absolutely worth the investment.
No, you're not going see this benefit in the first month of learning it. It'll be incremental over years of using it.
As far as configuration goes - Yes, you can spend lots of time in configuration, just like new linux users tend to spend years distrohopping. But it's not necessary. I suggest that if you learn vanilla emacs first, you'll figure out which keybindings you really need to change later on.
My configuration has been stable for years, and the only time I need to edit it is if I've added configuration for a new package. I don't use overlays like evil or doom, so perhaps this provides a bit more stability, I don't know.
There's a market for a customizable text editor. Look at what non-programmers are doing with Obsidian. The outdated defaults Emacs uses kills off their chances of getting into that market. Weird default shortcuts for no reason, a block cursor by default, strange terminology in the documentation, excessive keystrokes in the keyboard shortcuts (C-x C-s to save rather than C-s and C-f to search), and the list goes on. When someone gets to the point of customizing, they're happy with Emacs, but Emacs does everything it can to run them off before they get there.
Another thing they need to do is make sure they have the best markdown mode in the default install, complete with Pandoc integration. As good as it is, org-mode is not what most people are looking for when they are writing a text document.
> Yes, make Emacs appealing and user friendly. But don't forget that a masterful tool in the end requires mastery, which can't come for free.
That's true, but why add all the unnecessary baggage for new users? Just make the editor function like any new user expects and let the customization options turn them into passionate users.
Hands off the block cursor, it's very helpful with astigmatism.
Especially as a beginner being used to normal text editing, but even now after years of using it my reasoning is still "do I need it before or after the cursor" and looking at the block.
What's your reason for not wanting it by default?
In Emacs, you mean?
> a block makes perfect sense.
In Emacs. As it is now, i.e for existing Emacs users. Do you think this discussion, "How to make Emacs more popular", is mainly about that tiny minority?
> Especially as a beginner being used to normal text editing,
"Normal text editing for beginners" has been defined more by Windows Notepad than by Emacs since about five minutes after Windows Notepad was first released, which is over thirty (thirty-five?) years ago now.
> but even now after years of using it my reasoning is still "do I need it before or after the cursor" and looking at the block.
Your reasoning, and perhaps most other already-existing Emacs users'. Which, in the larger picture, equals practically nobody. What was this discussion about again; something like "How to make Emacs more popular"?
> What's your reason for not wanting it by default?
The more relevant question is: What's your reason for wanting to confuse everybody else with this weird behaviour?
Unfortunately this is a persistent false narrative to which many new users fall victim (as I believe you have). I maintain several packages aimed at non-coding writers. I put a lot of effort into ensuring that writers never need to write or understand any code in order to get writing.
Emacs has a built-in user-friendly options UI system that provides documentation on every option and its available settings, and provides input error checking. All options are organised hierarchically, or you can search for any options matching a string.
But, there are a lot of programmers out with a desperate need to appear clever. Using the options UI is an affront to their cleverness, so they insist that writing code is the only way. It keeps them feeling clever and it perpetuates this idea that the only way to use Emacs is by learning how to manipulate its internal code.
So we have people sharing their overly complex configuration files. And worse, these horrible "starker kits" that obfuscate the extensive in-built help, and further abstract the program away from the user.
Ignore anyone pushing any of those "starter kits". Ignore anyone who says "just paste this code into your init". They're only trying to appear clever. Anyone trying to appear clever usually isn't.
Edit: here's a video where I set up Emacs from scratch to a full-featured screenwriting program, without a single bit of code: https://www.youtube.com/watch?v=Be1hE_pQL4w
I use it very occasionally in order to discover the name of one of Emacs's thousands of user options, which option I then manipulate with Emacs Lisp code added to a file. I much preferred the (recently completely removed from Gnu Emacs after 2 decades of being marked as deprecated) vastly simpler list-options command for doing that.
For me, easy modification of one's personal software environment by adding Emacs Lisp code to files is the central argument for Emacs and cancels out the negatives such as the fact that, e.g., C-z does not undo the latest editing action.
One of benefits of online discussion of things like editors and programming languages is that it is a constant reminder of the largeness of the diversity in cognitive styles and preferences among people.
Customize could stand improvement in terms of widgets and layout, but it's not bad. Other than a coat of paint, it's pretty similar to VS Code's preferences interface.
On reflection, what inspired me to chime in on this thread is amazement that there exists at least one person who is enthusiastic about the fact that Emacs has thousands of customizable settings. (M-x customize exists solely to make persistent and ephemeral changes to those settings.)
Anyway brb, I'm off to customize how EXWM assigns workspaces to monitors when I plug my laptop into the docking station.
Emacs is held back by not being easy enough to extend, because it uses Emacs Lisp? I don't see how. I'd expect learning to write plugins for some application to be harder than figuring out enough syntax/semantics of a language to call library functions.
In any case, learning Lisp is useful, even if you never write an Emacs plugin.
If I actually believe that the time will be well spent, I'm willing to spend it. Having gone through the effort of learning emacs (yes, reading a whole book about it) and forcing myself to use it as my primary editor for a year, I have to say... I don't think it was time well spent. vi, however, was. It was (at least) as hard to learn initially as emacs was, but for most text-editing tasks, it's still a lot faster than any GUI editor both to start up as well as to actually perform text editing tasks. Plus, it's always there, no matter how many jump boxes you've ssh'ed through.
Emacs supports customization needs to the nth degree, but I've found that this is a false economyy.
I agree Emacs needs to be easier to get started with.
I can see that with different priorities, perhaps VS Code might be a better fit. But does it work in the terminal? Can I edit LaTeX and have equations rendered in-place? Can I easily switch layouts from having 3/4 panes of code and nothing else on the screen, to having various other bits around? Does C&P trivially support multiple "buffers" (registers in Emacs lingo; can copy & paste persistently to different places). Can I easily record rich keyboard macros - ones that, dunno, search second and third word on a line, replace first instance of second word with third word, then return to the starting point?
I suspect the answer is yes to some of these questions, but no to most. And this is barely scratching the surface of what Emacs can do.
But productivity isn't my only goal.
I want to give back to the community: Emacs is introspectable enough that it allows me to easily contribute.
I want to explore a different UI paradigm, which blurs the line between user and developer.
I want to support a grassroots developed editor.
Org mode is the main productivity multiplier. How do I do that in VS Code?
Any time I read a comment where VSCode is the obvious alternative to Emacs, it's a clear sign the commenter knows little of Emacs.
Take a look at last year's EmacsConf and count how many of the talks are about SW development (hint - minority). A very large number of Emacs users do not use it for SW development, and stating they'd be more productive in VS Code is simply false.
At the end of the day, Emacs and VSCode are extensible environments and editors, so there's gonna be a lot of overlap and some fringe cases that are only possible on either one.
But VSCode is definitely the more immediate of the two. I can install VSCode, sign in with my GitHub account, and immediately have my exact same environment as on any other machine. Any change I make to my environment, such as keybindings or installed extensions gets synced to other installations. I can remote into other computers and again have my same environment, developing as if I was on that computer itself. If I see a colleague with a certain behavior, all I usually have to do with VSCode is ask what extension it is, install it, and then I get the same behavior without any configuration (with Emacs, everyone has their own little custom environment). I don't ever need to be writing Emacs Lisp just to use the environment as I would expect to. You simply cannot do all of this with Emacs with the same usability and immediacy. And this alone is why I use VSCode.
I have tried getting into Emacs. At one point, I was on Windows and needed to run MIT Scheme, which doesn't really work on Windows, so I installed and ran MIT Scheme on Windows Subsystem for Linux (WSL). Through some configuration of my .emacs file I was able to get things up and running by using Emacs on Windows and then calling into WSL and Scheme (this is before the days of official GUI support in WSL). It didn't really work in the end, despite all the hackery, one reason being Emacs' terminal is its own little custom thing. So I install VSCode, install the Remote - SSH extension, and I was off and running within minutes developing in a Windows GUI with code running on Linux, as if I was just on the Linux machine. So I never looked back. Any experiment of mine for Emacs meant I spent all this time trying to configure the editor to do what I'd expect rather than doing what I actually wanted to do. With VSCode, I have found that I rarely spend time needing to bend it to my will. It basically does what I need, and if not, there's extensions or simple configurations that accomplish it. I'm almost always working in VSCode and not working on VSCode.
> Any time I read a comment where VSCode is the obvious alternative to Emacs, it's a clear sign the commenter knows little of Emacs.
This is also why people stay away from Emacs.
That most of the talks are not relevant for SW Development, and VSCode is likely not the correct thing to point existing Emacs users to. Looking at the talks from last year, is VSCode good for:
- Writing novels
- Produce sheet music
- Editing audio files' metadata and tying it to producing a web site.
- All things Org mode
- Roam-like wiki
- Creating fonts support for native American languages
- Reading mail/newsgroups
- Using it as a computer algebra system
- Interacting with external programs like the browser
Note: I do 3-4 of the above regularly.
I honestly have not checked if VSCode can do these things - will be happy to be informed.
Part of the problem you raise kinda comes from the newfound popularity of emacs, people started more projects on top of emacs and now we have a paradox of choice.
That said emacs core is pretty stable, even though there an acceleration in new ideas there too, it's not breakage inducing.
About ease of extension, in emacs you can add functions, menus, buttons, libs in 15 seconds. That's less time than it takes Eclipse to "create" an empty plugin project.
emacs is not the easiest (or the neatest or any -est) but relatively speaking, it's still a good thing.
Spacemacs might be nice but it’s in no way required in order to be productive with Emacs. My personal .emacs file is only 32 lines long (28 lines of comments are not counted).
Emacs has no user-friendly command names (you need to memorize function names which are often meaningless abbreviations), no autocomplete, and doesn't show available functions.
Equally, there's a difference in target audience. Do you need a tutorial to operate a screwdriver? No. Power drill? Arguably yes. CNC mill? Dear God please yes. I don't think you expect a fork lift or nail gun to be accessible with zero runway by anyone, or for their features to be discoverable by trial-and-error.
You could argue that this is not a worthwhile niche, and maybe that's right (at least for you and like-minded people) but it's just what it is.
You need i, escape, :w! and !wq. hjkl too if you're feeling fancy. But i, escape, :w! and !wq is all you need to use Vim. I know because I used it like that for two years in college.
I once pissed off dozens of customers by symlinking vim to emacs on one of our shell servers (back when isps gave you login access to a Linux/Unix box...
(Yes, it wasn't very nice, but it was funny)
My impression is that you are not familiar with Emacs.
I've tried recently to steal some features from VS Code but nothing fundamental came up. I've discovered the gitlens' git-blame overlay feature but it is cosmetics (I use magit-blame). btw, the feature is available as blamer emacs package (just add the corresponding (use-package) elegant declaration to your .emacs).
I use tramp to run remote commands using Org-babel all of the time. Obviously, emacs can edit remote files just fine too. What am I missing?
Emacs-devel are keen for it, and eglot.el is a good contender for inclusion.
Based on what you've been claiming I doubt that.
Emacs doesn't have autocomplete built in but it does have tab completion and if you press tab it will show you possible functions that start with what you typed if there is more than 1 option available.
I think most of the trouble people have with Emacs is that it doesn't use standard terminology or conventions mainly do to its age. There is nothing more discoverable about Ctrl-Z vs. Ctrl-/ other than that Ctrl-Z became the defacto standard. If you took two novice computer users that have never used a computer in their life I think they would have just as much trouble with VS code as Emacs.
“If you need a dedicated tutorial for a text editor it's a great sign that something is very wrong with its design, particularly concerning discoverability.”
I don’t agree. If it was a mass-market product for users who just wants something convenient, then I would agree. Those users are probably better served by other applications. (Word, Evernote, OneNote, Notepad++ etc etc) But Emacs is a power tool for power user. Therefore I think it’s okay that it needs a tutorial to get started. You need to invest some time to learn in. That will, in my experience, pay off greatly in the long run.
Let’s take an example from another domain:
Suppose someone wants to get started with 3D Graphics. I’m pretty sure software like Blender and Maya also needs some kind of tutorial in order to be useful.
And what tools would that be?
What is it in particular?
I see some UI operations block on TRAMP operations which is laggy and annoying.
I've used VS code as well, it's fine for what it does and certainly much more beginner friendly.
I got into a habit (obsession?) of automating as much as possible everything I repetitively do on a computer by writing elisp. It's essentially my operating system.
Isn't this precisely the kind of "protestant work ethic" that you mentioned just before? If someone enjoys writing ELisp for Emacs, what's wrong with writing 61k lines of it?
I recently started using Doom Emacs and really like it. There's a learning curve, but in contrast to what you're asserting, every other IDE has at least a similar learning curve. Unless by "text editor" you mean no IDEs, but then VS Code is out too, and I'm not sure what we're talking about.
This solves a lot of the shortcomings of vanilla emacs.
For a newcomer there is a "curse of Emacs", helm? ivy? ido? Wnat to do Python? elpy, lsp, etc
It's easy to get confused and just give up. Having a curated config like Spacemacs helps to get it working out of the box IMO.
Sometimes I ssh into a machine that has only vim installed, so I use vim. Sometimes it is faster to open a file using vim, so I use vim. If I expect to spend a lot of time editing it, then emacs.
Currently I am using IntelliJ for a Java/Kotlin project.