I have realized recently that a value that is gaining a lot of importance for me is the stability of my cognitive investments, in terms of tooling, across a time frame that goes beyond my "current project", and more into the "my entire career" territory. In that sense, I feel more and more that the choice of learning and owning Emacs, more than 20 years ago, while in school, has paid off tremendously, in the sense that it has always constituted a solid and consistent backbone from which I can always start a new project, no matter what the context is (corporate or personal). I feel this would have been harder to achieve with a tool which is asking me to update it every 3 days, and which periodically introduce important paradigm changes forcing me to reconsider the way I work. In short, I value Emacs' stability and consistency across time and tech fashions more than anything else, as I grow older.
This is the reason I left the whole app ecosystem. Apps are cool, and sometimes really great, but there’s no sense of permanence, no guarantee that your data will survive for long, that the app will be maintained, or that future devices will be able to run the app or access the data.
Yeah, I still use the boomer vocabulary: there is system software, and application software. The first category is called "operating system", and everything that runs on top of it is an "application". And outside of the old quip ("Great OS, shame about the editor") Emacs is AFAIK not an operating system but runs on top of one, so it's an application.
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.
I’m fine with “application” and “app” having different meanings.
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.
That sounds good in theory. But if you're working with a more-than-30-year-old tool, you're either:
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).
What is more innovative, a light IDE with plugins written in JavaScript and backed by a big company or a small Lisp machine disguised as a text editor where every key is bound to a Lisp command and every changes and extensions in its code or extensions can be tested interactively in a "live coding" environment, where the user is empowered to modify and extend what he wants?
I don't care about innovative in that sense, I care about features - what can my text editor actually do, and how well does it fit with how I use my computer in other cases.
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 of the IDE functionalities Emacs can be behind. Like debugging, or jumping to function definition (it depends of the languages and extensions).
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.
So I think you're actually wrong on some of these. And again, I say this as a massive fan of vim and emacs.
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.
I think the way vscode is currently managed, it won't hold up to time if the trend continues. A competitor that strips the baggage might just kill it, even if there is a lot of user content by then.
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.
i was looking into vscode/vscodium recently (i'm emacs user, but arguably more comfortable in javascript than emacs lisp). if you want to define a custom function do you have to write your extension? it seems like settings.json, is just that, a json file, as opposed to emacs config where you can drop a line into your config or even just eval some elisp in a buffer and have it modify your editor...
basically it seems less hackable, is that a wrong impression?
It's for sure less extensible than EMACs/Vim (you probably can write extensions but I've never done it, but it's not as easy as popping in some elips or whatever).
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).
The way I usually put it is you have a choice: learning your tools in depth or relearning old skills each time your tools tools. I decided upon the former and firmly believe it was the right decision.
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.
I agree with you, I like my tools to just work. I last changed my windows manager when I started using wifi regularly over a decade ago.
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.
2021 and Emacs still my preferred editor (and I'm young enough, in my 30's). Yes it requires a bit more setup (not much more however, VSC also misses functionality out of the box). However that setup is saved forever, across machines in the form of your .emacs file, so whatever changes you make to make it personal stay with you. And it's really not much more difficult to setup, Emacs lisp is more intuitive than JSON files and as a programming language, it's pretty easy to understand that you invoke a function and then just pass it parameters, and that's about all you need to understand about it to set up the editor anyway.
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...
> But there's literally nothing I don't have with Emacs that other editors provide.
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 ;)
Fix-it and renames work with lsp+clangd. More complex refactoring would be nice, but in the end what is supported depends on the lsp-server capabilities.
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.
> But there's literally nothing I don't have with Emacs that other editors provide.
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?
>Yes it requires a bit more setup (not much more however, VSC also misses functionality out of the box)
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.
VSCode allows you to export settings and keybinds via JSON files.
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.
Well, JSON is "just" a serialization format. I'd expect that to be much easier to teach someone than a programming language. That's a rather bizarre comparison.
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).
Yes, it is a bizarre comparison because of that fact. A programming language will never be more intuitive than "just a serialization format".
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.
I wonder why people are so focused on intuitiveness, especially in the case of programming languages.
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?
Be careful not to mistake ubiquity with intuitive. It’s arguable that BASIC is more intuitive than Javascript, but Javascript is more ubiquitous. That only tells us that it’s more popular, but not why.
>Plenty of Emacs plugins invoke a compiler, language server, whatever to get information about the code.
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.
For example, in C++ in Visual Studio I can click on a class member variable or method and rename it and the IDE will rename all uses of that variable or method and not get confused about other classes with the same name.
struct Foo
{
std::string name;
int age;
};
struct Bar
{
std::string name;
double weight;
};
Foo f1 = ...;
Foo f2 = ...;
Bar b = ...;
std::cout << f1.name;
In the code above I can select "name" on the last line and rename it. The Foo struct and all instances of name via f1 or f2 are updated to use the new name. Bar and instance b are untouched. AFAIK, Emacs can't do this.
Such renaming is part of the LSP protocol, so any LSP supporting editor (Emacs, nvim, etc.) will support this as long as the used language server does. I can do this with clangd and Emacs, but it's not Emacs specific anymore.
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.
Speaking as someone who sees a lot of students start using text editors for the first time, VSCode has two massive advantages over Emacs:
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.
> 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?"
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.
I've used Emacs for 30 years, and I have no intention of ever giving it up, but IMO this is somewhat accurate. The package installation and configuration story on Emacs has gotten a lot better over the last ten years or so, but there really ought to be a kind of meta package installer and configurator that does exactly what VSCode does: when it finds a file that it doesn't handle specially but for which there is an existing package or set of packages, install those packages and configure them with reasonable defaults.
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.
I was thinking the same thing. I use spacemacs and have moved to about 5 laptops over the last five years. Just bring along the .spacemacs files and any supporting tools like ripgrep etc and I am up and running.
I've probably spent less than 50 hours total over 20 years on my emacs configuration. But it wasn't all at once. And now I just copy the .emacs file between systems. Tweaking it is maybe minutes a year now. If I want to do something with, say, Go, I just download the appropriate mode. The longest time spent was when I had a few bespoke languages at work that had no text editor support in any editor. I wrote some minor modes to support them, that was probably 10 hours total with most of the time on the first minor mode, and the rest flowing quickly thanks to the prior experience.
EDIT: For comparison, I've probably spent 100x that (if not more) on Linux configurations.
I don't know about you, but my toolkit, which I'm perfecting, is programming language paradigms, design patterns, algorithms, programming language SDKs, popular libraries and frameworks, etc.
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.
> I don't know about you, but my toolkit, which I'm perfecting, is programming language paradigms, design patterns, algorithms, programming language SDKs, popular libraries and frameworks, etc.
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.
> Well that's great but none of that gets anything done. You need to be able to write programs effectively.
:-)) 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.
Not the OP but yeah, it's definitely up there for me.
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.
my setup is 200 line long. on a new machine I just scp it over. many years ago they dropped support for automatically decoding files with a 'Z' extension, so I had to change that sometime in the 90s.
total time invested over 40 years - less than 4 hours.
Vim is different enough that when its fans say it's superior, at least some people think it's plausible enough that it's worth learning. And even if they don't become appreciably more productive by it, at that point it's sunk cost and they might as well keep using it.
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.
I personally love Vim because once you know how to work it, you can code extremely quickly. You don’t really even need any macros (though they can make you even faster) — I find the default commands to be fast enough that I consider vim to be an “expert interface” for text editing.
The fact that vim-style modal editing can be implemented in other editors is huge. I use console vim frequently, but when I need to bump up to something more IDE-like (VSCode or a Jetbrains IDE), I can carry 99% of the vim functionality I use, and be up and running with a minute or two of config.
Computer Science students would greatly benefit from an introductory-level course in the two of the most historically influential languages -- LISP and Smalltalk.
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.)
Not always with those two languages, but in many CS curricula in the US there is a "programming languages" course that covers between 4 and 10 [0] languages in different language families. Prolog and Common Lisp (or Scheme) are typically included, you may get Smalltalk in there depending on the school. It's brief, because it's one course, but it's usually a 3rd year course so students should be competent programmers by then (that is, an Algorithms 101 course but in Lisp would be a slog for them).
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.
[0] The most I've seen, it was absurdly paced, an intern was taking that one.
You'd certainly want to avoid spreading yourself too thin, which is why I specifically limited my hypothetical first-year module to these two languages, as they would provide the (IMHO) ideal context for learning the rest.
> 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?"
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.
> 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.
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.
Emacs' fundamental problem is that in text editing, there are many equally good ways to do things.
It's equally good for Undo to be on control _ as on control z. It's equally good for scrolling to move the cursor as to not move it. It's equally good to have Lisp as a scripting language as JavaScript. No, really, I mean it. It's not a big deal in the big picture.
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).
This sounds like it's not written by an actual Emacs user... and the fact that I can tell points to the real fundamental problem of Emacs: it's not a text editor but the real thing it is is so complicated it finds it easier to market itself as a mere text editor.
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.
This is something I wish someone had told me 20 years ago when I first started using emacs. The whole "it's a text editor, but also it's not really a text editor"-thing was very confusing initially.
... 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.
You just succinctly described why my annual attempts to learn Emacs never actually go anywhere. As much as I like the idea of an all-purpose text processor construction kit, even with "starter kits" I spend a week trying to configure various languages to a point that I'm happy, find myself copying, pasting and tweaking Lisp code, invariably find weird conflicts that lead me to do web searches (which may find more Lisp code, which may be a decade out of date), and so on. I don't doubt that if I kept at it I'd eventually reach nirvana, but I frequently find myself thinking "this was just so much easier in Vim" -- and any time anything can be described as "easier in Vim", it feels like a sign of a UX problem. :)
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.
It does, although I've gathered that I managed to try my last attempt during a period when the released version was unusually buggy around the margins. What I'd frequently find was variants of what usually happened to me with Emacs: (1) find something that wasn't enabled that I wanted to do that could (apparently) be solved by enabling a layer (or installing a package or two), (2) enable that layer (or install that package or two), (3) immediately be confronted with unexpected error messages, (4) go on a bug hunt in which at least half the web search results were variants of "I ran into these unexpected error messages, how can I fix this".
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.
I haven't personally used VS Code much, but from what I understand, it still runs in two castes that don't, generally, mix: there's its core code, and then there's plugins, and the latter exists on a separate plane from the former. You can't write a plugin that redefines some core behaviour. The functions internal to the core are not all automatically accessible for any plugin. Plugins don't become fully integrated with the core code to the point where the source file location is your only hint as to whether behaviour comes from a plugin or core functionality.
(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!
Yeah, exactly. For example, evil-mode is still miles better than VSCode Vim plugins just because it works everywhere. Any buffer that my Emacs opens I can still use my Vim shortcuts (so it doesn't change that I open a text, a binary, file manager, a fuzzy search or PDF). Compared to this, on VSCode I basically need to explicitly say "make vim commands do this in this context" for everything I need.
My current client wants all of us to standardize on VS Code at some point, and this is by far the most annoying thing for me. I hate that if I leave the editor, it goes back to a mouse-driven design. I'm glad to hear you can change the behavior, so I guess I'll just have to do that at some point to make it work for my needs.
This is the main reason I changed and do most of my work in Emacs, keyboard only. Using it in terminal is a bit of a bonus. Onivim2 seems promising in bridging the gap, but we'll see.
No, I do not go "Emacs plugins can do what now". I rather go, "and that is supposed to be a good idea?". If you want to use Emacs as an OS, doesn't protected mode seem like a desirable feature?
From personal experience, I've benefited way more from that than I've been hurt by it. Whether that's true for all people I don't know.
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!
Unless I was very unlucky in my decisions about what and how to learn about vscode or my ability to learn has dropped more than 10-fold between the time I learned to modify Emacs and the time I tried to learned to modify vscode (which is unlikely but not impossible: it was an interval of 28 years) emacs is much easier to learn to modify than vscode is unless one is already a web dev.
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.
> If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well?
Almost, but not quite. VSC doesn't give you javascript access to the internals of the application, it just provides a fairly broad set of extension APIs. You can see this in how the VSC equivalent of rainbow-delimiters-mode (parentheses and brackets recolored based on their nesting depth) had to be rewritten as part of the core application for performance reasons. This wasn't necessary for emacs.
I'm doing a highly integrated language environment for a research language and faced this decision recently.
elisp and javascript are both pretty iffy lisps, but at this point I think I'd prefer javascript.
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.
> VSCode presents an API around a specific notion of what a language is and how it interacts with the editor
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".
By its nature software designers have to make some decisions on what should be easy, what should be possible and what you'd be better off using some other app for.
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.
Emacs is not that much different there with it's C-core and lisp-land. It had even a similar case with the reimplementation of linenumber-mode in C for performance-reasons. The question is more what emacs can offer generally that vscode is lacking in ability, even just theoretically. Because in reality there are of course many features not implemented yet in vscode.
> If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well?
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.
> 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.
Let's face it, the fact it's free software is the reason it's used at all, the reason it's been hacked on by so many people, etc... It's always relevant to discuss it's free nature, especially when discussing it's popularity.
eLisp? Where lexical scoping is this brand new feature that generates compiler warnings? Where the UI thread is the same as your eLisp thread? Where multiprocessing is a super clunky fork-exec with a weird side buffer? Where a simple regular expression works differently between what the user invokes and how you'd write it in a function?
Elisp arguably has worse warts than Javascript. For example, non of Javascript's legacy 'var' scoping nonsense compares to elisp's archaic model of using dynamic scope for everything by default. On top of that, modern Javascript implementations are of extremely high quality, whereas Elisp is stuck with an interpreter of mediocre performance.
Not exactly, VSCode is more of an editor that can accept very advanced plugins. The "virtual JavaScript machine with a standard library for writing graphical (text) applications." is a web browser.
I have not played with VS Code a lot, but I get the impression that, yes, they aim for something similar. I'm not qualified to judge, though, how successful they are so far.
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.
Also, there is an effort replace the old lisp engine inside emacs with GNU Guile, which is a JIT compiler that supports Scheme, ELisp, and Javascript. I have not tried it so far, but it might become possible to customize and extend emacs with Javascript in the not-so-distant future.
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?
I honestly don't know about the state or progress of Guile Emacs. I know it exists, but I haven't followed it beyond that.
Assuming it gets "finished" (is any software ever finished?), it should be no-brainer as long as it provides backward compatibility with old elisp code. And open up the emacs ecosystem to Scheme and Javascript, which could make it much more attractive to newcomers. But, as they say, I'll believe it when I see it.
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?
Is that like what the GCC-emacs project is doing with libgccjit? They are working (and have a great start on it) version of compiling most (all?) elisp with libgccjit to speed things up a bit if I understand it correctly. I have compiled it myself and it is most certainly faster to load and do "intensive" tasks faster than stock emacs. I've loaded both DoomEmacs and SpaceEmacs successfully with it.
In a couple months I'll have been using emacs for 30 years, and it seemed like a pretty good summary to me. In that time the closest I've gotten to using any of the lisp stuff is setting some variables in my .emacs file. (and it's been fewer of those as the year go by)
I never claimed to be an emacs user. I've used Linux exclusively at home since 2001, and I've never "switched" to it or vim, though of course I have a passing familiarity with both from such things as certifications or working on other people's machines.
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.
Thing is the difference between Emacs undo tree and …other editors undo is way more than the key binding. Your comment barely scratches the surface of the issue.
It's an early web browser. Elisp is an early JS. Viewing documents is just a little more complicated (download packages, sync stuff down using Git, etc)
>>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.
Well then in that case, ship a better Lisp than emacs lisp?
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.
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.
It's absolutely true that defaults are "bad" in many modern environments (though remember C-z to suspend in a terminal environment makes perfect sense!).
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").
I find this at least a little frustrating. I haven't used Emacs, but when using other apps that use non-standard defaults (or just defaults that I am not used to), changing one shortcut leads to a cascade where I have to change many shortcuts. I now have to spend a somewhat significant amount of time configuring a new piece of software before I even know if I actually like it.
Shipping with some easily configurable presets to mimic other popular tools would probably help new users a lot.
Also, though this works with Emacs running as a server, I find it better to just quit emacsclient instead of learning to do something different depending on what environment it is running.
Nope. Again, context matters here. I never use emacs in a terminal; all editting of files on remote systems is done in a local X11 emacs over ssh. And this is not because of circumstance but because making that choice opens up more doors. I can have keybindings not just on C-z but ones that aren't representable in the terminal at all (e.g. I like to put end/beginning-of-buffer on C-. and C-,)
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.
Even better, I repurposed C-z as the prefix for all my custom bindings. That's got a couple of advantages:
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.)
You guys both got nothing on pressing Cmd-W on a MacOS terminal when you intend to copy a selection. :-( I swear whoever designed that UI must have been a vi partisan.
Yep, for me it's this. I don't know why others are complaining about the other way around, maybe it's because I thought of Emacs as being different from other editors right from the get go, but I doubt I've ever accidentally entered CUA shortcuts in Emacs. But Emacs shortcuts in normal editors while using school PCs was something I did all the time.
The biggest problem for me is the constant context switching between those defaults chosen 30 years ago and the defaults converged on by every other app I use.
Of course, no context switching is needed if you do everything in Emacs.
Actually, ounce I got used to Emacs choices I ended up liking them better. Hard to say why, I think it's that when you start adding more and more shortcuts, the choices Emacs made start to make sense in terms of maximizing all the various bindings.
I would be very happy if I could use Emacs’ text editing and text manipulation/navigation everywhere. Things like a real IDE with an Emacs editor. Or the IDE being controlled by Emacs. Or a desktop manager controlled by Emacs.
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've been using emacs as my primary editor since 1989. It has for that entire time been a PITA to configure. My first customization was to map backspace to ^H and map the insert key to 'nil.
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.
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.
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.
>>everyone "believes" it dead. Same goes for Perl.
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.
> elisp is dead. Not because it is dead, or deserves to be dead, but because everyone "believes" it dead. Same goes for Perl.
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.)
I see many people on here (likely non-emacs users) claiming that Emacs is obsolete/outdated/dying by completely misunderstanding its position in the ecosystem.
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).
I just love that for a moment here we’ve put aside our differences about emacs vs vi and focused our efforts on bike shedding which car analogy best fits. Peak computing culture.
I wouldn't waste keystrokes on the classic religious war being waged in this thread so I'm gonna throw my hat in this arena instead. I agree with you---that analogy sucks.
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.
I think the right POV is that Emacs is a text-mode Lisp VM, or at least the remains of one. Whereas vi is just a (great) modal editing interface. They are not comparable.
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.
VI is modal text editor (think JEdit). Emacs is IDE (think Eclipse).
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.
My eyes roll so hard at mentions of the “religious war” that my eye doctor has had to put them back in their sockets multiple times.
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.
you will never be as fast or flexible as an F1 car
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.
Having worked in F1 that's entirely wrong. A Honda Civic will not even beat a F1 car in the first gear, which goes up to 180km/h. With an unlimited engine of ~24k rpm and a chassis which sucks around each curve nothing can be compared to a F1. If there are curves. On a straight track there are faster cars for about 4 seconds, but then the F1 overtakes. Our usual estimate was that everything in a F1 car was about 1000x better than in other cars. Gearbox? Engine? Chassis? ECU, TCU, tires, you name it
You're really claiming that an F1 will beat a Civic on a gravel track? Or perhaps you misread?
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.
Gimme an F1 chassis and i'll put tractor tires on it for the snow. I'd be delighted to give it a try. I'm sure my mechanic buddy would help for the giggles too.
I'll defer to someone better informed than me but I understood that as a reference to the rules and regulations around F1 cars.
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.
There are a lot of rules to reduce cost, assure safety and to make it more competitive. You can not for instance have moving parts. If you could the top speed would increase a lot.
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.
It sounds like you know very little about either F1 cars or Emacs. Emacs is more like an older Toyota pickup truck – been around for a long time, ubiquitous, flexible, can carry a load, simple, there's an abundance of spare parts, and there's no problem with it that a good mechanic cannot fix – most problems can be fixed even by improvisation in the field.
I used Emacs, its a lot more than just a simple text editor, its more powerful than a text editor or even many IDEs. But the learning curve is too steep for most people. With VScode I can just install it and start working straight away, I cant really do that with Emacs. I dont want Emacs to die out or fade away, but lets be honest its for a much smaller group of users. It they want it to be be popular it would have to change, but then it wouldnt be Emacs anymore.
There's that condescending attitude again. In your fantasy land Emacs is an F1 race car, and everyone else is a CRUD-writing code monkey that drives a cheap sedan.
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.
With 15+ years of daily Emacs usage, I couldn't agree more. It's 50% force of habit, and 50% the few commands (align-regexp! kill-rectangle!), packages (magit! tramp!), or custom Lisp snippets that make every other editor feel inadequate...
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.
> but no matter what, you will never be as fast or flexible as an F1 car (GNU Emacs).
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.
There are people in this thread talking positively of ELisp (a shameful language even by the low standards set by other Lisp) and who thinks the emacs GUI experience is acceptable in 2021. Some are even arguing that having to write 1000 lines of the previously cited terrible language to get the UX behaviours everyone has been expecting from a text editor in the past three decades is a worthwhile time investment. I would argue that apparently they are numerous.
It sounds like you are saying that people who don't share your opinion on ELisp are blinded to its flaws... but that doesn't make sense. Are you saying that?
There's very little that they can do that Emacs can't. It's just that if you're on the easy path, the IDE will give you a pretty high-quality experience with very little time spent configuring it. The "easy path" supports more and more use cases each year, but my experience is still that the more custom your build system is, the more likely it is that you'll not get your nice IDE integrations. That's was true in the 1990s as it is today.
VS Code and JetBrains (various products) are my top recommendations for Linux. MonoDevelop is ok. It is hard to give a general recommendation because your needs will vary.
I've read a bunch of articles where long time Emacs users are put into a position where they have to achieve something on a tight deadline. Many of them try to muddle through their Rube Goldberg contraption of a local config and under time pressure or advised by someone else they try a modern IDE and suddenly realize why many professional developers use them.
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.
1. I'm a long time Emacs user (30+ years) and a professional developer. Trying to contrast one of these versus the other as you do twice in your comment isn't really helpful or useful.
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.
I split my time between Emacs, Rider, and VS Code these days. Of those, I spend the most time in VS Code.
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.
Often it comes down to working with larger projects written in multiple languages. If you are working on some bog-standard JavaScript project that runs in the browser, Node.js, or both, maybe you won't run into this stuff.
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.
Visual Studio can't do it at all, I'm afraid. That's why I'm not using it.
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).
> And modern IDEs support 2 languages at the same time. Heck, they support dozens if not hundreds of languages 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.
I wouldn't use Emacs for that, and I use Emacs since more than 25 years.
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.
Emacs is more like a car from a Mad Max film than it is an F1 racer: each instance of Emacs has been so heavily modified (often in haphazard, kitbash fashion) that it's only ever supposed to be driven by one person: its owner.
I think a better analogy would be comparing a Mercedes W123 (Vim/Neovim) with a Toyota Camry or Honda Accord (VSCode/Jetbrains) with a Jeep Wrangler (Emacs).
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.
I don't want to sound rude but I've never seen a well executed car analogy, especially when they use F1 racecars. Your analogy doesn't make the position of Emacs easier to understand at all.
> I've never seen a well executed car analogy, especially when they use F1 racecars.
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.
The VS Code/normal car and emacs/F1 racer analogy seems weak. VS Code can bring most of the functionality of a relatively well tuned and customized vim or emacs setup to a much broader range of developers, and with very little investment. Less time spent gold-plating and polishing an editor's configuration is more time spent solving actual problems.
There is no world, in which "flexible" and "F1 Car" belong in the same sentence. By design, a track car gets rid of anything "flexible" for highly optimized choices.
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.
I don't think your analogy holds up. If you race an F1 car alongside a commuter sedan, it is obvious to anyone observing the differences in performance, handling, traction, etc.
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.
Hmmm... I agree that Emacs is specialist, but at least half the reason I don't use it is that it tends to be fairly sluggish if you start really configuring it and using it.
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.
> claiming that Emacs is obsolete/outdated/dying
> run of the mill, mundane, forgotten-in-a-few-years, CRUD web apps, a normal _average_ car (M$ vscode)
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.
If you want to continue this analogy, I don't want a 30 year old F1 car. Also, as with old cars there is a bunch of people who are determined everything invented in the last 30 years is stupid, and we should stick with "good old reliable" things.
Most people want a newer car, that's picked up the improvements in safety and performance from the last 30 years.
A better analogy is a non fuel injector vehicle that doesn’t need electronics to fix, is old and consistent, that works the same. It’s like x.org, you can rely on it to not change the UI constantly (like gnome breaking something in every version).
I understand why there's all this concern about making Emacs popular--as software professionals, we've all seen a few tools that we use and love wither at the vine and die slow deaths. But the concern for _overall_ popularity is a little misplaced. There's more developers than ever, and the pie continues to grow; Emacs just needs a sufficient total userbase to stay maintained, and that seems already to be in place.
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.
I agree with this. I used emacs in the late 90s through early 00s, and it worked great. I pretty much stick with BBEdit these days, because it works great for my personal workflow. I never got into vim: I only learned enough of it to edit config files and the like when I shell into a computer.
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.
I see where you're going - but I've personally noticed that there are a lot of things coming along with these cloud infrastructure paradigms that have made me feel like my localhost text editing workflows are going to make me look and feel even more like an absolute dinosaur as time goes on. I can't speak eloquently on this as I'm still an amateur to these cloud infra configuration concepts and their real limitations on how I'm used to thinking about application development, but I hope this comment sparks some inspiration for someone else to do so.
I use Emacs (with Evil) daily, and despite having tried to move to other editors I'm locked into Emacs. Not so much because of the functionality of Emacs itself but because of plugins...
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.
Nvim has some plugins and features that do some of the things you might be interested in. Telescope[0][1] which is a fuzzy finder for anything you can think of (files, symbols, color themes, etc.[2]). The LSP and Treesitter stuff in nvim 0.5+ is also pretty cool. If you want to just try it without much work the Lunarvim[3] project comes with sane defaults and included plugins (including Telescope).
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).
The diversity in the emacs ecosystem has a hand in this I think. There are so many different ways to switch buffers: vanilla, Ido, Helm, Ivy, and all of the other ones I haven't heard about. This kind of diversity is unseen in other consolidated, centrally managed software ecosystems.
And those aren't just ways to switch buffers - they're options on a 'select among choices' dimension that's totally orthogonal to 'things that generate choices to select'. List of buffers, list of commands, list of files in a project ... can be presented, narrowed, and selected in an interface chosen by the user
Emacs is like Earth. You can't claim to "learn it" or "master it," but it's still the best place to live.
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...
Here's the major benefit of investing long-term into emacs.
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.
Emacs is not just for programming. Given the popularity of other uses (org-mode being the obvious big example) it's likely that text editing is the bigger potential market than programming.
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.
The block cursor serves a very specific purpose. Since you can insert either before or after the cursor a block makes perfect sense.
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.
> The block cursor serves a very specific purpose. Since you can insert either before or after the cursor
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?
To be more popular Emacs needs to be easier to get started with and easier to extend. If I have to read a whole book or learn an entire new programming language, I'm not going to put the time in. If any time I search for "how to do x", I get a disjointed mess of "but spacemacs...", "in prelude...", "this custom elisp snippet..." where every piece of advice can be potentially incompatible with any past or future modification that I've done - then the effort and frustration doesn't seem worth for a text editor / org tool.
No! Emacs does not require the user to learn any code in order to use it.
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.
This is the first time in my 29 years of Emacs use that it has occurred to me that someone out there might like M-x customize enough to hold it up as a pro-Emacs argument.
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.
I'm actually in-between on this. What I normally do is write short bits of code (generally `use-package' forms) to install and load packages and set options that are essential to the operation of the package, are not private information, and don't vary between my different machines. Then I use `customize-group' to set any remaining options.
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.
I agree that M-x customize is not horrible at what it does.
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.)
At least two. The vast range of customizable settings is one of the main selling points of emacs for me, and I find M-x customize a very pleasant way to discover and tweak them
Anyway brb, I'm off to customize how EXWM assigns workspaces to monitors when I plug my laptop into the docking station.
I don't see it as either/or. I just set `custom-file` to something else to keep options settings out of the way, while I still have plenty (too much) of my own init code.
Emacs would benefit from being easier to get started with? Yes.
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.
> If I have to read a whole book or learn an entire new programming language, I'm not going to put the time in.
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 fits so nicely into my workflow. I can use it, feature-rich, from terminal, within tmux, and easily switching from the editor (where I write code) to other terminal panes (where I run the code). I can also use Emacs without any mouse input at all, have a rich set of keyboard shortcuts, and where I find myself doing something repetitive, I can easily automate it. While I'm at it, I can use the very same environment for a ton of other things - note-taking, editing more file types than I could care about etc.
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.
> You would probably be more productive in VS Code with an empty config.
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.
I took a look at the EmacsConf talks and didn't see anything in particular that stood out. Mind pointing something out?
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.
> I took a look at the EmacsConf talks and didn't see anything in particular that stood out. Mind pointing something out?
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
- Gaming
- 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.
If you find emacs hard to extend then i hope you never use eclipse, more on that later.
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.
When I set out to learn Emacs in the year ~2001 or so, I just did C-h t in order to launch the builtin tutorial. IMHO that can still be a viable way to get started.
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).
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.
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.
Vim has a built-in tutorial too. As said elsewhere, you literally cannot get started in Vim without knowing a dozen command and grokking modes, in Emacs you can at least stumble around without knowing anything.
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.
> As said elsewhere, you literally cannot get started in Vim without knowing a dozen command and grokking modes
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.
Ctrl-z followed by killall -9 vim is how I usually exited vim.
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...
You used emacs for 7 years without learning that it very much has auto-completion, you can see available functions with fuzzy matching, and that you can easily alias any function to any name or key-binding you want instead of memorizing it?
Could name a single specific feature that somebody who uses emacs for years is missing? (perhaps, a link to a video if it is hard to describe concisely would be useful)
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?
Sorry for misunderstanding. I see now that you meant autocompletion like LSP (rather than M-x minibuffer completion). Emacs could benefit from built-in LSP, I agree.
Emacs-devel are keen for it, and eglot.el is a good contender for inclusion.
Emacs has user friendly command names, functions in Emacs have a full command name. Can you guess what "comment-region" does? That's right it comments out the currently selected region. Or "switch-to-buffer"? That's right, it's used to switch buffers. Obviously if you use these things regularly typing all that gets tedious so you can use keyboard shortcuts like C-x-b to switch buffers instead. Sometimes these have relation to the command they call but sometimes they don't, but neither does something like Ctrl-Z (What does Z have to do with undo?).
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.
Emacs was founded in the 1970s. There is a lot of legacy in there, but IMHO it still holds up as a very powerful and nice text editor.
“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.
There already exists better power tools for power users, that are easy to use and easy to customize, yet still more powerful than Emacs. It's a common misconception that if it's arbitrarily hard to understand, it must be something for power users. Bad design is not a feature.
You need dedicated tutorials, or equivalents, for all complicated tools and machinery. The power of Emacs (with respect to text editing capabilities) comes from mastering, by committing to muscle memory, a large number of key sequences. There's no easy way to do this- it takes time and effort (100% worth the payoff imo).
That's some kind of protestant work ethic. It doesn't need to require days of busywork to be powerful. VS Code is more powerful, easier to configure, and more productive out of the box. The default feature VS Code offers make hundreds of lines of Emacs configs with dozens of custom plugins look laughable. Tramp mode is pure trash compared to remote editing in vs code. Stuff like syntax highlighting, intellisense, git integration, and other useful features are years ahead of Emacs too. Every language, including C, is supported better.
Yes, it takes work, it's like learning how to dance, draw, or paint. My emacs config is literally 64183 lines of elisp + 2356 snippets (just checked), so I'm not really considering a major editor switch at this point.
I've used VS code as well, it's fine for what it does and certainly much more beginner friendly.
Imagine what you could have accomplished if you didn't have to spend all that time writing an entire large codebase just to make it usable. It's a false assumption that it should require pointless busywork to be useful. You're never getting back the time you've wasted on writing a config for an obsolete editor.
I love writing elisp, obviously! It wasn't some drudgery for me, it was the whole reason I even got into coding (from using R in emacs) in the first place.
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.
> Imagine what you could have accomplished if you didn't have to spend all that time writing an entire large codebase just to make it usable. It's a false assumption that it should require pointless busywork to be useful. You're never getting back the time you've wasted on writing a config for an obsolete editor.
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?
This is kind of an odd attitude. I haven't used VS Code, but I have used PyCharm extensively before. There's a) so many buttons everywhere, with hovertext that doesn't help unless you already know what you're doing, and b) so many things buried in random configuration screens.
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.
"No autocomplete" and "doesn't show available functions" are a matter of bad defaults, rather than lack of capability. There are great packages for them available, but even in core, there are OK options (ido-mode). I do wish that the core team would "bless" great packages and work towards bringing them into core and into the defaults.
Helm is a little heavy-weight. Ivy is lighter, but also does a lot of NIH stuff it doesn't need to. I personally like selectrum, (https://github.com/raxod502/selectrum) because it provides the features of Ivy and quite a bit of extensibility, while still only using the built-in extension points in emacs (completing-read-function, etc.). I do wish the emacs developers would bless something and include and configure it by default, though.
There's a new builtin icomplete-vertical mode in Emacs 28, but I assume that like so many defaults, switching is deemed socially infeasible, so we are stuck turning it on ourselves.
Just because it is expensive to learn Emacs doesn't meant that it isn't worth it. Fine, you aren't "going to put the time in". But what do you get then? A mess of programs and plugins that need to be replaced, rewritten or reconfigured all the time, and its not even close compared to a well managed Emacs setup.
I never had to read a book to use emacs well. Same with vim, VSCodium, and IntelliJ.
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.
