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.
I've been using Emacs for the better part of 30 years. Right now, I use it less than ever. I've switched to using JetBrains IDEs for programming. JetBrains replaced VS Code which was nice, but required a lot of time dealing with plug-ins that the JetBrains IDEs don't. The full IDE with tightly integrated deployment, language tools, really advanced code completion, documentation, source control, debugging (and remote debugging), code profiling and project management is just 20-30 too many plugins to manage in most extensible text editors. I still use Emacs for remote text editing and org-mode, but that's it. The UI problems in Emacs are not a "round corners" problem. Emacs is a great console app. But GUI Emacs is sabotaged by it's excellence as a console app. Emacs' autocompletes, tooltips, forms and dialogs are more mid-80s terminal UIs than GUI native. I suspect putting a full, comfortable GUI on emacs is a hard problem. You can't even resize an emacs window with the precision you can every other app on Linux and MacOS (no idea on Windows) because it forces resizes based on line height and character width (or something that approximates that).
In the end, Emacs isn't bad software. On the contrary, it is excellent, but it's excellent at being a text editor that is native to a terminal, that runs well as a GUI app. It still is very useful, but it is not competitive with newer ides and through the web capable editors.
> You can't even resize an emacs window with the precision you can every other app on Linux and MacOS (no idea on Windows) because it forces resizes based on line height and character width (or something that approximates that).
Well, so does PuTTY, the (AIUI overwhelmingly most) popular remote terminal emulator on Windows. Which AFAICS is quite appropriate for a text-based program in a GUI window. So if there are problems with Emacs, I don't think that is among the biggest ones.
I've been using emacs for approximately 30 years. Every once in a while, someone ask me what editor or IDE I suggest they learn, and I never suggest emacs. It's incredibly powerful, but it's a fossil.
I keep using emacs mostly because of muscle memory.
I'm relatively young and for me Emacs isn't a fossil just because there isn't a better alternative I've found for taking notes than Org mode. This is especially true if you want to embed LaTeX or code into your notes (and even execute it).
As I've gotten into learning Lisp and using Magit occasionally I can't think of a an editor that's more versatile in its extensibility or offers a Git interface on Magit's level (although I still mostly use command line).
I did rebind a lot of stuff to more common shortcuts, with the exception of C-c just because it was too much work.
This may be more of an argument for Emacs as a general editor than IDE specifically however.
That's it. That's the reason. You can usually get Emacs key bindings (or a shallow approximation thereof) in most editors. But yeah, we're stuck, so I guess we just gotta double down.
It is fun when the young 'uns do a double take after you execute a particularly fancy macro. I do love that.
The macros are always the deal-breaker. I tried sublime text, set up emacs keybindings, then tried to ctrl-x-( to start a macro and... switched right back to emacs. (and then proceeded to modify me emacs config so it approximated many sublime text features)
I used to be a heavy Sublime Text power user a couple years ago. I found out at some point that while Sublime does market itself as supporting macros, many commands were one of these four
- extremely basic (ie, move left or right)
- poorly thought out
- Straight up not implemented as a recordable macro command
I've customized my setup to the point where I don't just want emacs keybindings, I want my emacs keybindings. Because those are the ones that are in my fingertips.
I think it's interesting that there are Emacs users who use it for so long and yet still regard it as a text editor.
For me it's a window manager, mail client, terminal emulator and so much more and I don't know of a rivaling ecosystem where I could get these things in a consistent way. Maybe something Apple makes, but that's a non-starter really (especially if you care about keyboard accessibility).
Same situation for me, but much longer than 30 years. I still use Emacs with SBCL Common Lisp (but use VSCode if I am exploring someone else’s large codebase) and for routine non-programming editing, but otherwise I use IDEs: LispWorks, PyCharm for Python, IntelliJ for Java and Clojure, XCode for Swift, and Racket IDE for Racket Scheme.
I like having Emacs key bindings for other editors and IDEs.
As an Emacs user for ~10 years the greatest deterrent is it being single-threaded and lisp. I just can't understand the love for it. I've spent countless hours customizing my own configuration and I just can't enjoy lisp. Emacs's source code is also hard to understand and contribute to (let's not talk about lisp.h).
I'd rather have a new editor (or emacs fully re-written) with the same mindset as emacs - near-full customization via a modern scripting language (lua?) and/or c/cpp plugins, and text-centric. I don't care for fancy UI or buttons it could even have the same look and feel which I love
That an emacs user holds that opinion is a bit surprising to me, as to me most of the reason for me using emacs is to develop in lisp-inspired languages. I think lisp development is the raison d'etre for emacs in the modern times.
As someone who loves fennel, clojure, scheme, etc., I find myself drawn to emacs because the (repl driven) workflow is so good. That said, I've found that I can't give up vi-style modal editing. The interface matters to me. So neovim it is, for now.
I'm going to go out on a limb and suggest that Lisp is, in fact, an albatross hanging around Emacs neck.
Using Lisp (and especially elisp) is not okay. Lisp has some very sharp corners that simply are not acceptable in modern languages. I use Lisp when I'm very resource constrained but still need an interpreted language--otherwise I use anything else.
Dynamic scoping is just stupid (fault of elisp). Not being to operate on a sequence is stupid. cons pairs to build everything is stupid. nil() terminated to signify lists is stupid. The pervasive necessity of metaprogramming macros is stupid. An inability to type things is stupid.
Lisp/Scheme encased itself in amber in the 1980's and refused to keep up with genuine improvements in programming languages. Sure it meant they missed out on the collective brain damage that was design patterns and object oriented--but it also meant that it missed out on good things, too.
Take a very hard look at Clojure and look at what parts of Lisp/Scheme Rich Hickey put a bullet in and which parts he kept. The Lispers still excoriate Clojure as "not a Lisp" and that perfectly sums up the problems with Lisp nowadays.
> Not being to operate on a sequence is stupid. cons pairs to build everything is stupid.
There are other sequence types than lists in elisp and pretty much every other lisp out there. And what do you mean with "Not being [able?] to operate on a sequence"? [0] contains a bunch of functions for operating on sequences, and it's notable they don't say list but sequence in their signature. They work on multiple types of sequences, not just lists.
I do agree on dynamic scoping by default, that's a major weakness in elisp.
Lisp "lists" (cons pairs with terminating nil) act kinda sorta like sequences (although the elisp names don't agree with Common Lisp names)--until you need length() and your algorithm blows up to O(n^2) or you replace a value and your list walker blows itself into a mess. This is part of why Clojure shot the idea of building lists up from cons pairs and gave explicit syntax for certain sequence types and made them fundamental.
Which would be fine if all the pedagogy didn't teach stupid cons-pair lists and recursion as THE fundamental pieces of Lisp when they should instead have a gigantic red klaxon saying "Don't use these outside of toy programs as they're a maintenance and abstraction nightmare."
Other grief: #() syntax makes read-only vectors. The syntax for what is basically [] is every other language: (make-array 5 :fill-pointer 0 :adjustable t) I can go on and on and on about the usability disaster that are sequences and collections in Common Lisp. And then let's add the joy of a Lisp-2 on top of everything else.
The problem is that the Real Lisp Programmers know to ditch those and go grab better abstractions when doing Real Programming. However, the extra abstractions are just annoying enough that stuffing things into an unlabeled list is too convenient. So, you see a small number of good abstractions and a bunch of little unlabeled "containers" passing data around with cadr and caddr. There is a reason why a "labeled struct" is a fundamental part of most languages and gets its own syntax.
And even "Practical Common Lisp," which like I like very much, introduces macros before collections. And look at how much time it spends on vectors and hashes (which are FAR more important to building most programs) vs cons-type lists (this ratio holds even as far back as Touretzky in 1986--it's gotten a little better over the years). And then people wonder why nobody uses Lisp for real programming?
So, sure, you can use the Common Lisp standard--and get saddled with a bunch of good design decisions from 40 years ago that now look absurdly stupid.
Or, you can use Scheme which has nothing built in and construct it all yourself. Oh joy.
Alternatively, you can just use a modern language that made design decisions in merely the last decade.
> Sure it meant they missed out on the collective brain damage that was design patterns and object oriented--but it also meant that it missed out on good things, too.
The "collective brain damage" and other similarly derogatory epithets that OOP regularly gets slammed with is AIUI actually Java "collective brain damage"; it doesn't necessarily apply to all forms of OOP.
1) It was in fact mostly C++ brain damage. "Design Patterns" predates Java by quite a bit.
2) OOP isn't a unified thing. There was a paper way back that mentioned something like two dozen "characteristics" of "OOP". And then proceeded to point out that "Smalltalk" chooses these, C++ chooses those, Java chooses these, and that there was a lot of disjointed-ness between the definitions.
Yup. So the vaunted "brain damage of OOP" is more a matter of the "brain damage" of C++'s / Java's choice of which of these traits to implement and call the result "OOP".
(Personally, I largely agree -- and I say that as a fan of a basically very similar OO language, Object Pascal [as seen in Delphi and Free Pascal / Lazarus], which could also be seen as an imperative language with bolted-on inheritable templates of records with method pointers called classes. It just made a slightly different, and better [IMO], choice of exactly which of these traits to implement, and that makes a all the difference to me.)
There is something weird about projects that choose a functional programming language as one of their pillars. When I read nixos documentation, there are constant references to how awesome and pure and functional their language is.
That was mostly a "tongue in cheek" joke : ) What I meant was that the code base is overwhelming both because it has some years on top and I don't like/understand lisp that much
There is a some effort in Nim, called moe[1]. Nim has a lot of features similar to a Lisp, and is both compiled and scriptable. Of course, it requires contributions to make it usable as a daily driver, but I guess that is somewhat the point. The vision is sound imo.
If you need to install a dozen plugins (helm, projectile, company/autocomplete, flycheck, whatever else) to match something that's installed by default in any modern text editor, Emacs will never be remotely popular. Even something as simple as theming doesn't work by default; each theme needs to be implemented separately for every mode. 99% of people will see how fruitless it is to try to configure it and move on. Why waste time on fiddling with configs?
Emacs' user base is probably larger than any time before.
Granted, market share dropped because many people are never exposed to Emacs (or vim), directly start with PyCharm, VSCode, etc.
The question is: Can emacs increase its market share by becoming more approachable? Probably yes, on the other hand since Emacs is so different to the User Interface expectations of 2021, it will always have a hard time.
I myself have been a hardcore vim user for now 20 years, in the last 2 years I have made an effort to learn Emacs and like it quite a bit. I am also a VS Code user at work.
> Why waste time on fiddling with configs?
Config fiddling is not specific to emacs. The time I spent fiddling with VSCode configs and plugins, or IntelliJ config. The difference is that with emacs I see the result of my fiddling in the form of emacs lisp code that I can store and easily transfer from computer to computer and for the IntelliJ stuff I had to take notes on what I changed where so I could reproduce it.
I just find it a little saddening although very understandable that at this point Emacs just simply isn't better for writing code than any Jetbrains product.
Yes I'm very aware that there are plugins, stand-alone terminal tools to integrate, language-server-protocol and all that... But it's just that Jetbrains tools have far deeper intelligence about your code. By default.
I tried hard to like Emacs, and I did end up liking it, I just don't know for what workflow.
Knowledge work? Obsidian
Working on large coding projects? Jetbrains IDEs
Working on scripts or quick edits? Sublime Text or sometimes vscode
Need to make a change to bla.config from the terminal? (n)vim
I think the only advantage Emacs really still has to offer nowadays is that it's general enough to be able to do all of the above very well to quite well. None of those tools comes close enough to be able to do all of those workflows. Yes you can force sublime or vim into becoming a workstation for all of the above, but then it will become very bloated and slow.
It also doesn't help that Emacs is very archaic. I can teach you Obsidian, Sublime and vs code in a day, I can teach you jetbrains IDEs in a month, but it will take me years to teach you to use emacs effectively.
> Working on large coding projects? Jetbrains IDEs
IME language support and a desire for intellisense type features is a bigger factor. JetBrains generally has excellent support for that across the board, and it's sometimes lacking for some languages with Emacs
but size of the codebase doesn't really matter. At work we have a sizeable PHP codebase, and it's just as fast, if not faster, to navigable with ripgrep and fzf or editor plugins based on them as with a JetBrains IDE
> for the IntelliJ stuff I had to take notes on what I changed where so I could reproduce it.
IntelliJ (and all other variants), stores setting in code (xml) too. It's not as exposed or clean as a single .vimrc or .emacs.d/init file but it does the job. You can easily export the settings or have them auto sync via your jetbrain account.
Exactly that, plus it doesn't really serve well as platform. I mean VSCode renders Markdown previews correctly, not some ASCII based approximation. It renders images if I happen to click on one. Extensions can actually provide decent UI, thank's to that CSVs never looked better in my text editors.
Both the examples you give seem kind of arguable; I'd almost say they demonstrate the opposite.
The problem with VSCode's built-in Markdown previews is that they're not extensible, so there are a variety of alternate Markdown renderer plugins, for example to better work with the various wiki-like Markdown plugins. Emacs also has Markdown previewing, but it is extensible by design.
I'm not an expert in either VSCode or Emacs (I use both off and on), but inline image handling seems like it works better in Emacs. I've never figured out how to show Markdown images inline in the actual text editor part of VSCode (as opposed to the preview), whereas that's super easy in Emacs.
your argument that a text editor is not going to be popular because you need to install a dozen plugins to match what would be considered "modern" doesn't add up. I can see a thousand reasons why emacs is not popular but having to install plugins is not one of them. VSCode itself needs a bunch of plugins for certain languages, and even if you used it for the out the box languages (e.g. JavaScript) there's a couple of things missing that and IDE would have out the box (I agree that emacs would need much more plugins compared to VSCode).
Also, look at vim/neovim. They are still one of the most popular text editors (much more popular than emacs for example), look at the stackoverflow developer survey, in the last one neovim was ranked the most loved text editor and vim is ALWAYS ranked between on of the most used editors. You need a dozen plugins if you want anything close to a modern IDE, yet they are still very popular and used.
Agreed about plugins. The main nice thing about VSCode is that it installs and reasonably-configures needed plugins as needed (though Spacemacs does this, too).
I've used Emacs for about 5 years now, exclusively in Evil mode. One of my biggest complaints is that my big complex configuration setup seems to break every time I migrate to a new version of Emacs, or a new computer. This last time, I had to install VS code to get my work done quickly because I didn't have time to mess around with my configuration (yet again). It was surprisingly easy to get up and going on vscode. If it wasn't based on Electron, I just might consider sticking with it. Tweaking Emacs consumes a lot of time and seems to never end.
Have you tried any package manager tool that support taking a snapshot of your current whole setup (i.e. all the exact package version you are using)? Then on your new environment, it can be restored by the snapshot you saved before.
The speed to 'first development environment' (lol) is a day and night difference between VSC and Emacs. VSC is faster to setup by several orders of magnitude (even if you know Emacs). Overall I believe you can get the same functionality, if less customizable, in VSC.
I can't remember the last time by VSC configuration broke. I guess there isn't much to break in it.
I fell for the "text editor only" meme 8 years ago. I'm actively a vim user that uses tons of plugins just to be able to do simple things that IDEs do by default. I would not recommend it to anyone.
I work primarily with embedded systems (ST and NXP MCUs). Not working with the respective IDEs that have been specifically designed for this type of work and using a text editor instead (of any type) would be objectively a bad choice.
There is just so much value in being able to visually configure pins, peripherals, clocks, etc. that just the text editor makes no sense. Also the debugging experience is probably order of magnitude better.
What you can do and what does make sense is vim emulation inside of the IDE. It is not perfect, but it is what it is.
There is A LOT of ideology in the software world. DO NOT FALL for it. Take things at face value. Be a pragmatic, not an ideologue.
I’ve been an emacs user for 10 years. Before that, vi for another 10.
This year I switched to VSCode and I will probably not go back.
I like emacs, but the modes I depend on are just too brittle, and there is no easy way to discover that your old favorite mode for some particular feature set has been surpassed by a new one in popularity. VS Code plug-in search gives you ranked options.
Also, there is something to be said for having everyone on your team / company on the same editor; you get economies of scale w.r.t. setting and configurations. As someone that personally invests in tooling, it’s nice to then be able to scale that tooling out to 50 people and have everyone get the benefits.
I can’t do that with emacs, because the learning curve is too steep. But I’ve been able to switch dozens of people with VSCode.
I was a vi user for a decade also and decided to try vscode and never looked back. I’m really not sure what it is about it but i just don’t fight with it. Since then I’ve also switched to PyCharm for python editing
I’m surprised at the disparity between Emacs and vim use (20% vs 3% according to some survey). I thought it’s more equal.
I suppose, while the learning curve for Vim is a lot steeper, you reach the power regions very quickly too. With Emacs, while it’s less alien initially, you need to learn quite a bit more to get to “power user” levels. But then, in turn, it seems that Emacs is much easier to mold into an IDE sort of thing, whereas this seems against the Fu of Vim. One tool, one purpose.
Any probability distribution of any attribute can be aribtrarily cut off at the 90th or 85th percentiles to make this point. Are you claiming there's something special that relates integer multiples of standard deviation of the IQ distribution to emacs usage?
Jokes aside, definitely not a day's worth of tuning.
My minimal set-up is mostly hiding all the GUI elements. Though I also make a semi-virtue out of trying to use as much vanilla Emacs as possible, for this very reason.
If you know your way around it, there's a lot of power in unmodded Emacs still.
Stuff like electric pairs, rainbow delimeters, rjsx-mode, prettier, and neotree are really all I use. I started using emacs because of auctex writing my master's thesis, and ended up switching from vim because of the experience. Once you know the basics about packaging (enabling melpa) and setting a comfortable theme you're pretty much ready to roll.
Prefacing with that I don't think iq is the best way to measure intelligence, but I wonder what the intelligence distribution of tinkerers is. The sort of person who might sit down to learn emacs because it's a blank functional canvas that you can customize to meet your particular needs.
What I like about Emacs is the things you learn from it. The “config file” is a program, not a JSON or INI file. This allows the user to add functions to the editor very easily.
For instance, one of the first tricks I taught Emacs to do was to find the right font size so I could have at least 80 columns on a window. It was a bit of work, and needs to contemplate some corner cases, but it’s really cool to be able to do that in your config file.
This is a pattern other programs and frameworks use. It’s relatively normal in Python to import configuration from a settings.py file that’ll do whatever is appropriate to get the information (a bucket with an INI file, constants declared in code, a local settings_devel.py file…)
The complain about the weird and twenty year old issue in Gtk questionable[1]. Gtk2, X11 and disconnecting a display and Emacs calls abort().
I cannot speak about EMACS because I prefer VIM and NEOVIM. My requirements are usability - where VIM excels with your knowledge (learning curve) - and LSP-Support. The later is provided since NEOVIM '0.5`[2] nearly ready to use. A modern editor should know what the user is actually doing and interact with the compiler, spell-something (languagetool?) or whatever :)
LSP with NEOVIM? Requirements:
1.) VIM-PLUG
2.) NVIM-LSPCONFIG
3.) NVIM-CMP
Your compiler will provide everything. In my case CLANGD for C and C++. Setup isn't hard but I would appreciate a HowTo directly at neovim.io or even built-in NVIM-LSPCONFIG and NVIM-CMP within the package. Because figuring out is hard, setup is not. Where GNU needs to catch up quickly is LSP with GCC, the compiler doesn't provide a user back-end. This is important and actually I want know what GCC things about my code - I'm using GCC to compile. EMACS and VI-Family will greatly improve through this. You don't need to like Microsoft because of LSP - but LSP is great.
Strongly agree that there should be a GCC LSP server, and that Stallman's objections to the GCC features that would be needed to make one are Not Helpful.
I love Emacs, but you need to be a retro minded programmer to enjoy it, that means you have to prefer code as your user interface, because in Emacs, code is the main UX, you're basically living inside a running Lisp command shell.
Now honestly, I don't think it needs to become more popular, I think it just needs to continue to attract enough people that are smart enough to work on future versions and maintain the popular extensions, and that's all.
I would worry if people started moving away from Emacs as text-centric. My biggest complaint with VSCode (which I do fully expect to take over and to which I will one day presumably have to migrate) is that there's so much damn UI for things. The terminal window isn't just a buffer of text like everything else, it's its own ungodly window that pops up differently. Most extensions are primarily UI instead of keyboard and text driven. There's a nice Magit clone which does things properly, and I'd love to see more effort on things like that. But fundamentally VSCode doesn't seem to have the right level of abstraction to allow all this.
The problem with VS Code is there is *not enough* UI. I desperately would like to have some toolbars and menu options, because the kotkeys and key-chords VS Code uses, where they aren't following conventions, are not easily discoverable.
They're in a bind because they are trying to straddle a market where you've got emacs an vim users to one side and Visual Studio users to the other. Some ability to customize the UI, even if it were provided by a plugin, would be helpful.
Are they not discoverable via the command palette? I find Emacs very helpful here, commands are always prefixed sensibly and you can do fuzzy search on them anyway. You can run 'apropos' if you're really stuck and help is built in to every function. It'll show you bindings if you don't know them and invoke a command directly etc etc. I feel like VSCode has most of this. Besides, they're your key bindings anyway, I think it's worth investing in whatever's ergonomic for you given you'll likely spend a decade or more with an editor. One annoyance I had was that extensions were regularly changing commands and throwing away my bindings though.
I should be clear though, I am not suggesting they strip it to the bone at the expense of other users' tastes. I just hate that I can't do that _myself_ because it's not quite as low level as Emacs.
It's difficult to discover a command with the command palette if you don't already know what they've called it.
I dunno, I'm old. I use directories and folders and hierarchical organization instead of searching when I'm allowed to.
VS Code is offputting enough and different enough in conventions from everything else I use that I don't have a great deal of interest in learning it's idiosyncrasies where they depart from standard UX.
This is the exact issue I have with VSCode. I don't particularly like the keybinds in emacs, but the killer feature for me is that everything is a text buffer. Eshell, magic, lsp, I interact with them all in a similar way from the keyboard. It was the terminal in VSCode that brought me back to emacs
I'm using GUI Emacs. There is one thing I use the mouse for: resizing windows. Apart from that, GUI is more visually pleasing, it doesn't try to emulate graphics by fitting characters into the grid. When it wants to paint a line, it paints a line, not a column of "|" characters; same with arrows and whatever. Another advantage is that it gets the key presses directly instead of through the terminal. In the terminal it can't distinguish between e.g. "C-/" and some other keys (I don't remember which).
However, I'm looking for a better editor anyway. Emacs is too unresponsive at times. I'll probably either switch to a GUI version of neovim when one of them gets good enough[1], or write myself a new editor, because I haven't really seen anything promising outside of neovim.
[1]: I think neovim folks might have abandoned this idea, so I'm not holding my breath.
Ignore the hater's comments. Emacs is Lindy[1], will be around for another 40+ years, and no amount of ankle-biting will change that. Having used it off and on for a couple decades, I can say with confidence that the Emacs community and ecosystem has never been stronger. And thanks to the LSP, it's comparable in IDE features to other LSP capable editors. With the new in version 28 type-inferencing JIT compiler[2], performance has also never been better.
Emacs outshines all other editors in two major respects: discoverability and extensibility. These are two sides of the same coin. When I say discoverability, I mean how the editor actually functions, not just reminders for what the keybinds are. The internal calls can be instrumented, advised, and even rewritten. And this ties into extensibility. In other editors writing an extension is a full blown project. Let's say you identify a need while you're doing your real work. In most editors you now have to create a new plugin project and set up a bunch of boiler plate before you can even get started. By then I've already discovered what I need to do and hacked a solution in the scratch buffer without getting dropped out of my flow for my real work.
There's no denying that Emacs has its warts and that Elisp has a lot of historical baggage. Those who don't grok the Lisp approach to interactive development will never be able to understand why even an admittedly mediocre Lisp is a more frictionless development experience than anything they've ever used.
A number of years ago, I reported a problem with its default Python mode and the way it automatically indents things. I got a response, which confirmed it was a problem. Then nothing happened and the report was eventually closed.
For me, that was representative of several other issues I had encountered over the years. It's a great tool, but it is 1) old and sometimes baroque ("make-frame" comes to mind), 2) so large, even if you consider just the built-in functionality, that they seem to have problems keeping everything up to snuff.
I am starting to move to Visual Studio Code. That's a painful shift, because I wrote lots of customizations in emacs, but, on the other hand, it has much better tools for many modern things I need to deal with (AWS, for example).
I love emacs, but it needs a replacement -- something with the same basic architecture, but more modern concepts of how editors work and maybe an extension language easier to get buy-in for than emacs lisp. I had hopes for Atom, but... that looks pretty dead.
I have worked at a number of jobs where it sometimes required me to use coding. I was not treated like a programmer ever. I was given very old hardware and expected to do my work. The worst computer I had was a Dell machine which had an i3 CPU and 4GB of RAM. Opening VS Code on this machine brought it to it's knees.
I solved this issue by simply using Emacs instead. It uses far less memory, didn't cripple my system, and it is after all my preferred text editing environment for the last few years. I eventually got fed up with Windows bluescreens that I switched to Linux, and then I spent more time fixing other people's older Windows machines than doing my tasks.
Emacs has me sucked in and I don't see myself going anywhere else. Now I'm using Emacs on another old Dell with Linux in another workplace, and it's fantastic to use as always.
When I started using Emacs, it was still written in teco. (I did use raw teco once.)
In all that time, I've NEVER customized or configured it. That was a huge advantage when I was working very closely with other people - they could use my Emacs session and (mostly) work and I could grab theirs and always work.
"Never" is not quite true. I borrowed someone's customizations for a year or two, but they weren't worth the hassle to move them to a new machine so I went back to "no customization."
Every few years, I ask "wouldn't it be nice if Emacs did {something}". I then find that someone implemented said something, and it's in the released version.
I've used full Emacs and Emacs style editors (mg, jove, epsilon) for over 40 years and programmed in LISP for longer than that. In the 1990's it was evident that Emacs was in decline.
For a couple of years, I used Vi because IBM's lawyers were afraid of the GPL; during that time I found Vi to be a superior text editor than Emacs. Sometime in the late 80's, Emacs and the GPL were accepted by IBM's planners, and I switched back to Emacs. Quite a few of the AIX kernel developers did end up using Emacs, even though Vi had its advantages as a text editor. It was the customizability of Emacs and the ecosystem of high quality packages that drew me back to Emacs. (For example, a developer on my team wrote the tower of Hanoi command. Try it out: M-x hanoi). Emacs became a general purpose tool for interfacing with your system. With Emacs, I didn't need a graphical terminal to work with multiple windows, I didn't need Norton Commander to have a powerful, portable interface to directory management. It has incredible outliner, mode for LaTeX, interface to git, etc., etc.
My point is that it wasn't the text editing (Vi handled that better), it was everything else, and that everything else was enabled by Stallman's brilliant insight that the editor should be built around a powerful interpreted language, LISP.
LISP was key to the success of Emacs. In the 1980's, people were excited about LISP; by the 1990's the excitement was wearing off. The LISP Machine companies weren't commercial successes. While some LISP compiler/interpreters performed well, Emacs Lisp was simply adequate. In CS programs, Scheme was being taught instead of the more fully featured LISP--Scheme has a simpler tighter core of fundamental features and consequently was a better choice for the ubiquitous undergrad Programming Language smorgasbord courses.
I needed an embedded interpreter to be a key part of a distributed network of servers I was designing. LISP was my choice, but my companies own, very experienced, developers rebelled. Smalltalk, Prolog, and even building our own C-based language interpreter were all viewed as more acceptable than LISP.
The way to make Emacs more popular isn't to persuade people that they want a customizable editor that requires a great deal of LISP expertise. That just won't happen. Pick a language from the one of the top 15 languages and allow Emacs customizations to be developed in one of these languages. Here's one measure of the 15 most popular languages[1]: Python, Java, Javascript, C#, C/C++, PHP, R, Objective-C, Swift, Typescript, Kotlin, Matlab, Go, VBA, Rust.
Out of the 15 languages listed above, many can be disqualified for obvious reasons: R and Matlab are not general purpose enough, Rust is far from interpreted and has a slow compiler, and so on. In my opinion, Emacs would be more popular if its core supported Python or Javascript or even Go (say running in a separately compiled process that interacted with the Emacs server via IPC). I'm not a Javascript person, but Javascript is likely the best solution; I would gladly take the time to learn how to use it for Emacs configuration and customization. If Emacs was customizable in Javascript, there would be an army of developers working with it.
I was nodding along to your recount until your recommendation for a new
extension language. It wasn't your selection of language that rankled so much
as the cavalier manner in which you suggest it. Replacing elisp with, say,
javascript is tantamount to rewriting nearly all of emacs, a product of
40 years (although presumably fewer man-years).
I agree with you that replacing all of the eLisp with say JavaScript would be impractical because there are hundred thousands of lines of eLisp that would have to be replaced, but Emacs is never going to increase its appeal while requiring new users to learn its own, somewhat peculiar, extension language.
Emacs out of the box is usable, but not as good as JetBrains tools or VS Code or Vim. Emacs is worth learning because it is an incredibly flexible editor construction kit that can be shaped into the editor one desires, but this, unfortunately, can require the user to write dozens of lines or even thousands of lines of configuration in eLisp.
The young programmers that I know are just not going to bother to learn eLisp to get their mode line to look useful. Spacemacs and Doom are good examples of how far one can push Emacs configurations, but even working with these prebuilt advanced configurations requires some delving into eLisp.
One approach to replacing eLisp would be to write a tool that compiles eLisp into JavaScript. eLisp has enough idiosyncrasies that this will be very challenging, but perhaps this could work. There are so many JavaScript programmers that could help with cleaning up the inevitable broken packages.
Alternatively, like the NeoVim project, most of Emacs internals could be left in place and a JavaScript extension language could be added so that new packages could be written in either eLisp or JavaScript. Someone would have to figure out interoperability between the two—sharing data between two interpreters each with different garbage collectors for example.
LaTeX faced a similar problem. The TeX esoteric macro capability was used to build LaTeX and LaTeX was used to build hundreds of complex packages to be used with LaTeX. The TeX/LaTeX world moves at a snail’s pace compared to Emacs, but they have made gradual progress in modernizing TeX and LaTeX (LuaTeX, LaTeX3, ConTeX, etc.)
Again, you wave your hands as if such a transpiler falls within a man-year of
effort when there is little expertise, much less funding, for work that is not
only difficult to get right but also not guaranteed to achieve the desired
effect of broader adoption.
So true! The dream of adding support for an additional extension language doesn’t fix the UI, the archaic defaults, unusual terminology, licensing restrictions, key bindings from keyboards used half a century ago.
It’s all very sad. The worlds best editor, one of my favorite tools, is now too big to renovate.
I used to toy with the idea of “fixing” TeX because I really liked using it, but again the fundamental problem that I wanted fixed was the extension language. I wanted something better than layers of macros on top of macros. Maybe I should stop musing about fundamentally transforming Emacs and go back to daydreaming of an improved TeX.
I have been a happy Emacs user for 25 years. Still gets the job done and is quite flexible with whatever code I'm working with, and hackable if I need to make it do things differently.
I read through the comments here a couple hours ago and heard all the same arguments that come up whenever folks talk about emacs vs. other editors|IDEs|platforms|OS's. As such, I didn't feel the need to add my own comment to the fray.
But as I was scrolling through the front page, the title of the article struck a chord.
I'd say that emacs was never popular. It is (and always was) a fairly niche product used by those who found something about it compelling.
Even "back in the day" emacs usage was dwarfed by vi (vim didn't exist), notepad, Wordstar, WordPerfect and even ED/EDT[1].
Full disclosure: I am a long-time emacs user (25+ years, preceded by using the Epsilon Programmer's Editor[0] -- a commercial emacs work-alike -- for 5+ years).
At the recommendation of an EE professor, I adopted EMACS as an undergraduate in the first few years of the 3rd millennium. I stuck with it for about 18 years, including stumbling through a handful of custom elisp scripts to get some stuff done that I wanted.
With the advent of VMs in data centers, I found that constantly installing EMACS started to become a real chore, and vi was just always present in base images. Also, always needing to remap caps lock and left ctrl was obnoxious, especially as I moved between Linux, Windows, and MacOS environments. So last year I bit the bullet and went fully into vi.
First I did some research into the scriptability of the editor, and upon learning that I could hook events via autocmd that call into custom Python code, that was it for me. I wasn't interested at all in struggling to figure out some arcane (to me) elisp invocation just to do some simple text manipulation, when I already knew Python well enough to just get done what I wanted with minimal trial-and-error. Plus the wealth of libraries available from pip and Vundle pretty much gives me all the extensibility and integration with other toolsets I could possibly want.
I spent some time practicing the key combinations for stuff I would effortlessly "just do" in EMACS: split window, jump to the bottom window in the frame, open a buffer, find text, highlight and copy, jump back to the other frame, record macro and run it 12 times, yank words/lines, re-indent region, etc.
Aside from muscle memory, there really wasn't anything keeping me with EMACS any more. I still am not quite as proficient in vi as I was in EMACS, but at the same time my career has moved away from 100% coding to more a mix of emails, documents, and occasionally some code, so maybe that has something to do with my departure from the EMACS world. I care more about the hassle of having to install EMACS in various environments I jump into as I'm working with nodes in the data center than I do about my level of comfort and proficiency in EMACS.
I think the only way to make Emacs popular is to get more users. And in any of the over six thousand human languages in use today: "Emacs user" typically means "a programmer". Emacs desperately needs more programmers.
Unfortunately, many of the core Emacs developers are also FSF advocates. Some of them have very radical and uncompromising views. It sometimes feels like they have little understanding of the real world and the software industry in general, and they live in the 16th century equivalent of the computing world.
I mean, many of us (software developers) are very sympathetic to the cause and the idea of liberating all software, but sometimes it just gets too crazy. As if someone tried saving the world by harassing palm oil plantation workers in Indonesia: "Why don't you try planting cedar trees instead?". Vilifying and fighting the evil in the industry is right; punishing everyone indiscriminately - is not.
One of the latest examples: a question about LSP server implementation for Emacs Lisp - the verdict of the people in charge? Nope, we shouldn't do it because: "it would allow editing Emacs Lisp in non-free programs like VSCode". Seriously? IMO, it's not just a simple non-sense, it actually sounds like borderline narcissistic schitzo thinking.
Emacs codebase needs to adopt the ubiquitous and familiar model of issues and pull requests instead of clinging to the outdated way of email threads and patches. That's what made Neovim popular. That's how VSCode achieved in just five years, what was like twenty for Emacs. That's why the most innovation in Emacs happens today outside of its core. Today GitHub, GitLab, and other Git forges have so much Emacs Lisp - it's probably the most widely used Lisp in the industry (maybe even comparable to Clojure and Common Lisp). And guess what? Authors and maintainers of those awesome libs and packages not sending patches over email.
I don't think Emacs is going to fade away anytime soon. But the strategic mistakes made by the core decision-makers have done irredeemable damage, and Emacs now doomed to play catch-up.
> Nope, we shouldn't do it because: "it would allow editing Emacs Lisp in non-free programs like VSCode". Seriously?
Emacs supports copy-paste, doesn't it? So you can already edit Emacs Lisp in non-free programs. Just paste it in from any JetBrains editor, or from MS Word for that matter.
I didn't start using emacs until (1) hardware became fast enough to run evil-mode with low keypress latency (because vim uses key sequences rather than chords and I type fast), and (2) Spacemacs. I switched to Spacemacs before there were a neovim, and if it weren't for spacemacs, I would have ended up with neovim instead.
I have not had time to really dig into the code and customize my editor. I installed Spacemacs, some layers, and know just enough to keep the things I am used to there (such as layouts), and that's pretty much it. I really enjoy how Spacemacs organized things, and it has made it much easier to learn.
I still typically use vim for quick-editing config files on remote systems.
I recently switched from emacs to spacemacs. I love the key bindings, but the Emacs GUI with spacemacs is so slow it’s unusable, keeps my laptop running burning full speed.
I use spacemacs remotely on a terminal with mosh and tmux, so I don’t notice. But back in ‘10, evil mode wasn’t usable for me on the terminal. I imagine spacemacs on 2010 era hardware would suck, let alone GUI.
I wonder if the new chips like the M1 would make a difference.
Emacs groks my soul. I can't defend it's flaws. But if I'm reborn a developer in a thousand years I sure hope it will still be around. Otherwise I'd rather be a shrimp or a dolphin or something (I hope those will be around too)
I’ve used emacs for years, and then vim before that for several years. I maintained my own config for a while, then moved to doom.
…while I eventually ended up abandoning notes in org for a dedicated tool, I love using emacs. My only issue is perf: on an M1 Max I get multiple freezes from LSP per day when working with typescript. I’m currently on the latest emacs-mac build (plus with native comp doesn’t seem to be that much better). The perf issues in a large typescript project are so severe that I’ve considered looking at other editors. A modern UI should just not lock up while waiting for a command to finish.
I've been using Emacs for 15y, I can't replace it. Emacs-server is just amazing for me.
I truly believe that its weakness is elisp, it's not hard but at the same time it's not a language you want to learn or spend time with, so of course that means less packages, less support and less interest in customizing it well.
Other than that, I would be quite happy to see a modern version, with support for another scripting language and maybe dropping all these UI features, like menubar, toolbar etc.
If we acknowledge there's a learning curve, the UI buttons are non essential. VSC & others are probably better at this.
I still feel the same way now about this article that I did then: Popularity is a misguided goal for Emacs. Emacs is a hacker's editor. Back when I started using it, the OS I ran it on -- Linux -- was niche, and the editor itself was niche of the niche. It seemed to come with "power users only" signs guarding it. It had its own diskset in Slackware because it was big and heavy and not the kind of thing every Linux user needed to have so you could easily exclude it. It's designed to be shaped into a custom tool that does what you need the way you need it done, as you work with it. Not everybody works this way, not every programmer works this way. Many enterprise shops aim for a software factory approach where there is one common, blessed workflow and you train people in that workflow and just plug them right into the assembly line. Those people make up the vast bulk of developers and most of them wouldn't know what to do with an Emacs if they had one. And that's fine.
When those people start crossing over onto Emacs mailing lists and going "What Emacs needs is to work exactly like my favorite IDE, else it will die in obscurity" I'm just like, psh. Go away. You've got your own great big ballfield to play in, why do you feel the need to come in and start trying to set rules for our little one?
In fact, this reminds me of a story. Back in the early 2000s there was a clown called Scott McCollum. An ultraconservative, he was fond of writing articles about how Linux and open source were communist cancer. McCollum had an acolyte named Joseph D. Wagner, who once trolled the gcc mailing list with a bug report about a TOTALLY CRITICAL SECURITY VULNERABILITY wherein gcc's optimizer would remove code to scrub sensitive data such as passwords from a buffer before reusing the buffer. When he was told "that's what 'volatile' is for" and to go fuck himself by the gcc maintainers, Wagner had an op-ed published on McCollum's site wherein he went "AHA! The open-source commies maintaining gcc don't care about your security! Use Microsoft Visual C++ if you want your software to be secure!"
Because of people like that, I don't trust entryists from outside a community. I have reason to believe there's a good chance they're not acting in good faith for the benefit of the project.
Emacs distributions I think is a good way to make it more popular. Out-of-box emacs install is very dry and unappealing. There are many packages which could be installed to make it much more modern and user-friendly. Emacs distributions which pack emacs with a list of packages and default customizations is the right direction. I've seen many new emacs users who started using spacemacs but would probably be put off by learning curve of standard bare-bones emacs.
This was super valuable as it showed me conclusively why Emacs is dead, except for a relatively small group of persons who were exposed to it very early in their careers.
Emacs is not now or in the future ever going to have "mass appeal" and that's okay. It caters to a niche, intellectually curious developers who like tinkering for its own sake.
If programming is just a job to you, that's totally fine. For a lot folks, programming is like accounting, a safe path to a decent paycheck. These folks will likely use VS Code and that's OK.
Not every piece of software needs to "eat the world". Some software, like Emacs, can just be enjoyed by a community of dedicated users.
Emacs likely has more new users now than ever before. I'd wager the absolute number of users are clearly growing. There's an order of magnitude more Youtube videos, blog posts, etc than there were 10 years ago. Getting Emacs help via a Google search often failed me a decade ago. Now it's extremely rare that I don't find an answer.
I used to be an emacs partisan, but line continuation characters killed it for me.
With vi I can cut and paste into other applications on the desktop, with emacs I can't.
I'm not going to accept the "just customize it" argument because if you do any administration at all you will sometimes log into a machine that you've never seen before.
Sometimes you're going to log into a machine that is damaged.
In that case you should be facile with whatever editor is already installed on the machine.
Emacs doesn't lend itself well to running on machines you've never logged into before, or ephemeral machines/containers/etc.
It's not a tiny sleek thing that you can start anywhere and have the same experience (that's nano or vi), but if you let your local Emacs eldritch horror reach out with its noodly appendage to whatever you're trying to edit, you'll have a much better experience.
I have stopped using emacs from the last 5 years since I had problems with its key bindings. My left little finger ended up paying the price as that is what I use for control key. I still miss org-mode which I used for more than 10 years.
It is one huge reason why I kept coming back to emacs even after all the hurt.
From then on, I used sublime and now vscode to do text editing and an IDE like IntelliJ for development. My left little finger has gotten a lot better.
Preface: I have been using Emacs as my only editor for over ten years.
This article is at once extremely funny to me and extremely frustrating.
Funny, in that it reads like a tabloid magazine article from an alternate reality where the goings-on of our savior RMS is the hottest gossip available, and Emacs is the topic du jour.
Frustrating, from what I perceive to be an impenetrable thickness from RMS and RMS-adjacent Linux contributors/Emacs users. People who use text editors just don't care. (not to imply that they ought to care.) It's not just that Emacs, as it tends to ship, is extraordinarily ugly. It's not just that Emacs is difficult to master, or that it requires knowledge of Lisp to be meaningfully configurable, or that it isn't friendly to new users. It's all of this and many more.
People use VS Code and Sublime Text and Atom and $EDITOR because they're simple on the surface, they're easy to install (you just download it and go), don't need heaps of customization to become useful, don't force the user into learning a completely new set of metaphors, etc. etc. The average developer just wants to write some code.
This quote got it the most right:
> [...] no Microsoft word user has ever considered themselves to have opened a "buffer". They open "files". They move "windows" around, not "frames." They cut and paste not kill and yank, etc.
As long as core usage of the basic functionality of the software demands users learn a totally new set of concepts, develop new mental models, and develop intuition for new design metaphors, Emacs isn't going to win over (m)any new users. It doesn't matter how much Emacs users try to evangelize (what ends up amounting to,) their system of beliefs, or attempt to proselytize their design as "best", or most well-reasoned. Unless Emacs ditches its fundamental philosophy that it ought not to "baby" the user by natively offering familiar and welcoming design patterns and a de-facto feature set that people living in this century expect by default, I don't see Emacs gaining meaningful share.
People use the alternatives because they simply don't care about the things that Emacs contributors care about. If, down the road, they end up caring, those alternatives do indeed offer plenty of reward for those who take the time to learn; it's just that with the alternatives, the ceiling is presumably much lower than for Emacs. On the other hand, the floor is much higher. With Emacs, the floor is somewhere around the molten core of the Earth.
Meanwhile, you have Emacs core contributors quibbling about rounding edges and custom icons; unable to come to a consensus about all manner of trivialities, when what they really need is a seismic shift in core philosophy. It reeks of impending irrelevancy and a gives profound sense that Emacs is deeply out of touch with what the average person wants, as far as their mission of actually getting people to use the product goes.
Judging from the discussion in the Emacs lists, they are not going to go anywhere.
This needs a few people that (a) want to do it, (b) have a specific vision of what to do (as in, they don't fish for random suggestions), (c) have the power to do it (even if others disagree).
This is totally feasible in, e.g. VS Code. In Emacs? Not so much...
Instead, there's endless bikeshedding and "change by commitee" with momentum-killing vetoes...
As a 'new' user (less than a year, and still customizing my init file), I can say that I started using Emacs because of org-mode and or-roam.
As a chemical engineer, my use case is that of being a researcher, programmer, and tinkerer. So, the initial appeal was that of having the ability to version-control, pre-process, and have 'reproducible builds' of my articles or documents (if I add more data, I wanted to be able to update the numbers in the article).
And, most importantly... I was drawn in by the capability of using org-roam to try out the zettelkasten methodology (even more so now that there's org-cite).
My journey has been to first slowly learn Emacs, then org-mode, and finally I'm starting to learn org-roam, and to learn make my own templates for my zettelkasten implementation.
Before all of this, I had tried using Vimwiki and Taskwarrior for productivity and knowledge administration, and I had also used PP and ABP as Markdown preprocessors with Pandoc for documents generation.
I still prefer to use Jabref for reference management (mostly for looking up by DOI or ISBN, and pairing with the PDF and epub), but I might try to eventually learn a way to go do that with some of the bibliography managers on MELPA.
For coding Python, specifically, I'm still fond of Spyder. But I also intend to transition and try out ways to achieve the same things that allow me to produce high-quality code (with rich documentation). I plan to re-learn modern FORTRAN on Emacs, however.
Anyhow, my experience of Emacs onboarding has been that of slowly learning what can or can't be done by searching for random snippets of init file configurations, and reading the Emacs and org-mode user manual. Also, by watching System Crafters' videos, as well as videos from other very talented coders and researchers that have shown how to use org-babel to create reproducible research.
Finally, I wanted to add that one of the best-selling points for org-mode and Emacs, is the ability to do so many awesome things just from plain text files, with very low memory and disk footprint (in stark contrast to VSC).
One thing I forgot to add is that I'm thankful for all the hard work that has been done in creating a cool ecosystem of software that has resulted from developers scratching their own itch. I have donated once, and will donate again... but I also intend to contribute and help keep free software alive.
I'm an experienced Emacs user but not an advanced one. What I like is the ability to have code in one or more buffers and a shell (CMD on Windows, bash on Linux) in another buffer. In that buffer I compile with `make foo` and see the output there.
I'm curious to know what people think about elisp as a extension language. Would Emacs be better if everything was implemented in elisp including the core data structures (assuming elisp was very fast)? Do people suffer from lack of static typing?
Elisp is nowhere near perfect, but it's fast enough in general. I recently wrote an indent function for a private DSL; it looks like a big slow mess, but when I run it on a code file, it does its job with no noticeable lag. You can write slow code in any language, of course.
As someone who picked up Emacs about 3 years ago, and now finds it to be my favorite editor, I think the only issue with Emacs is performance on large files and stability of builds on Windows.
Ehm. I think it's natural, and there's nothing wrong with that. I'm not a musician but I think, for example, guitar players do fetishize their instruments and have their favorites, no?
If anything I see more love for Emacs over the years, not less. From Spacemacs to DoomEmacs to all the vim users switching to Emacs+evil-mode. There's LSP support since a while too.
The Emacs ecosystem is alive and very well. It's in much better shape than it used to be.
I used to live inside JetBrains' IntelliJ IDE, starting at IntelliJ version 4 (yup, I'm that old) and I'd probably use IntelliJ again if I was forced to work in a nonsensical Java codebase, full of boilerplate, impossible to navigate because it became a gigantic mess of spaghetti code. But that is my vision of hell.
Emacs is something else. My custom config is about 3 000 lines of elisp code, written over the years.
About anything I want Emacs to do, I can have it do it.
Dunno, last thing I did was configure my 3-ways merge/diff environment: didn't like the default, didn't like the layout, didn't like the colors. Dived into some elisp code and I changed the layout to better match my very wide screen.
Another quick hack: when asking for the list of recent buffers/files opened, I wanted, for those in version control, to see how many commits they had (to quickly find hot spots)... Some elisp code to modify "counsel", one shell script. Boom, done. I've done that years ago. Still working flawlessly.
I've written a plug-in for IntelliJ back in the days. It's horrible.
Also if we compare Emacs to IDEs, it's the most lightweight, and by very far. It was "Eight Megabytes And Constantly Swapping" and it was funny joke in the 90s but today 8 MB fits in the L1 cache or so. It's not swapping anymore (even if it's a bit more than 8 MB, granted).
I'm using the native-comp branch of Emacs since it came out and stuff like burntsushi's ripgrep directly integrated in Emacs. It is not just a bit fast, but incredibly fast.
Sure there are gotchas. You have to dig a bit into elisp to fix the usual suspects (like long lines making it slow: it's all configurable).
But you're in control of absolutely everything.
You have the source code, use it when you need it.
Now I know some are using Emacs with the default setup and the default keybindings and without knowing / using any elisp. I'm no elisp guru but I think Emacs only begins to show its power once you being to use elisp to tailor Emacs to your way of working.
That's the thing: you adapt Emacs to your way of doing things, not the other way around.
I don't think there's any need to "make it popular again". It is popular enough and it is thriving.
I'm happy that Emacs community doesn't have a lot of those who think that "everything should be easy" and that working hard to learn something is a waste of time by default.
Not possible until they simply suck it up and pander to plebs. I can have a development environment setup in VSCode in under 5-10 minutes in most cases; you cannot even begin to understand Emacs configuration (let alone what you need to google). You need to go heavy into the language itself.
Emacs should have been what VSCode is now - a powerhouse of customizability that offers unmatched functionality by default. Instead it's a toy for some old people who are still holding onto the remnants of an age that passed a long time ago. Emacs is basically useless compared to VS Code, and its authors are what's holding it back. I don't see it bouncing back to popularity any time soon.
Anything you can do in Emacs, you can do in VS Code faster, better, and easier.
Emacs is being steered by a committee of living fossils that look condescendingly on people who expect a text editor to be discoverable, easy to learn, and productive out of the box. They make passive aggressive comments ridiculing anyone who wants Emacs to behave remotely like any other program. With this kind of leadership, it will be dead in a few years.
> Emacs should have been what VSCode is now - a powerhouse of customizability that offers unmatched functionality by default.
+1.
Emacs is a powerhouse of customizability, and it needs to work on functionality by default.
> Instead it's a toy for some old people who are still holding onto the remnants of an age that passed a long time ago. Emacs is basically useless compared to VS Code, and its authors are what's holding it back.
I don't think Emacs is held back by its authors. The article might not make it clear but RMS does not contribute much to the vision or code of Emacs today. Read emacs-devel, and though there's occasionally some conflicts, the authors are keen on progress aligned with what people expect from an editor.
Emacs is a complex platform, owing to its unique vision on blurring the line between user and developer. The authors do a great job of keeping that up-to-date.
If you need to use a specific dialect of lisp most people won't be familiar with, it does a poor job at it. Lisp is not a language many people use today. NeoVim lets you use any language you want for writing extensions. VS Code uses javascript which is easy to learn and most developers already know it.
It's a great strength that NeoVim supports many languages, and VS Code uses Javascript.
Lisp is not widely used, and this is an impediment to Emacs' popularity.
However, when people speak about Emacs customizability, they are referring to a deeper level of customizability than most programs (even NeoVim/VS Code), in which its innards and UI are all subject to modification, at runtime, within the beast itself. This isn't necessarily a good thing, but it happens to be my preference at least.
> Anything you can do in Emacs, you can do in VS Code faster, better, and easier.
Show me how to do the following in VS Code:
1. Org mode, or anything as powerful as Org mode (org mode is one of the two major packages that keep people in Emacs - it's not an obscure thing).
2. Reading, writing, and managing email (e.g. adding a tag to an email). While you're at it, please make sure the org mode equivalent can have a TODO linking to a particular email.
3. IRC
4. Feed reader
I honestly have not searched whether these exist in VSCode, so it would be nice to know.
Hey, could you please stop posting unsubstantive comments and/or flamebait to HN? We're trying for a different sort of internet discussion here—one that's different from the default, so we need everyone to expend a certain amount of effort avoiding that.
You're welcome here as long as you post thoughtful, substantive comments. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site to heart, we'd be grateful.
