Speaking as someone who typically uses Emacs as anything but an editor: Emacs is recognized as an editor because it was designed as an editor with macros (thus the name). Those who call Emacs an editor are rarely trying to diminish what it is. If anything, they call it an editor since that is the main entry point to using it and it is much less intimidating than emphasizing elisp.
If anything, the opposite is true: those who try to diminish Emacs point out the absurdity of referring to it as an editor. To them, what has been accomplished through elisp is more of an indicator of a lack of focus or of bloat than it is of Emacs versatility.
> [emacs] was designed as an editor with macros (thus the name)
no, that's not true.
emacs was written in the macro language of another editor, teco; teco had the macros. So, emacs was written as a new editor written on top of the old editor teco, and at that time, emacs was a set of "teco edit macros". As a user, where you used to run teco, you could instead elect to run the "edit macros"
because the authors of emacs were teco users, and macros were so useful to the teco user, yes, a macro facility was also added to emacs for the emacs users, but emacs itself was not intially those macros, it was teco macros.
The second Emacs was written for the Lisp Machine by Daniel Weinreb. There the whole editor was written and extended in the same language (Lisp Machine Lisp) in the same environment. There it did not have a separate macro language.
If you're a vim user but interested in trying out Emacs, I'd highly recommend Doom Emacs: https://github.com/doomemacs/doomemacs. I had been using neovim as my main editor for a while, but the vim bindings (evil) in Doom Emacs are excellent.
It was a lot to take in at first, so I went back to neovim. But I started using org mode more and more until I finally just went all in on Emacs. Now I understand that the editor war is pointless. Bringing vim + emacs together is bliss.
I actually used to hack on vanilla Emacs but then I switched to Doom Emacs. Why? Because, like many others, although I am interested in configuring my editor, I am also interested in getting on with my work. With Doom Emacs, if I want to install support for a certain language, I need only uncomment a line in one of the config files, run doom sync, and then support for that language is installed. But you're not really sacrificing any customisability so you still get all the advantages of working within Emacs.
Honestly the biggest blocker for me is just how slow emacs feels compared to (n)vim. Using both in a gpu accelerated terminal emulator, emacs just feels slower especially on larger files.
Granted, I have not tried to use emacs once the jit landed in 28 (or was it 29?). But it's something I really would really like to use since instead of having a different application for irc/mail/etc it could all just be emacs.
I'm using a Macbook (intel) for work and a linux machine (xorg, not wayland) for hobby related stuff. It's insane how much snappier and instant everything feels on the linux machine. Every time I'm tinkering with my config on my private machine, I'm let down when using it on my work machine as I need to dial down things I've enabled because emacs has gotten really sluggish again.
I've read similar experiences from people all around the net, but my linux machine is also a bit more powerful than my macbook, but honestly not enough to explain the worlds of difference between the two.
Nevertheless, on both machines I've noticed a substantial speedup with the JIT you've mentioned, so maybe give it another try?
The slowness of Emacs, or lack thereof, tends to be greatly dependent on the exact configuration in use. Out of the box Emacs should be as fast or faster than any editor you wish to compare it to, but the more fancy packages you install the more likely it is to become sluggish and glitchy.
With version 29, large file support has been very much improved. Not marginally but orders of magnitudes. But differently: Editing large files is now (very) usable.
Emacs is my daily driver, and even with JIT on an M1 mac I get a lot of stutter and freezes with LSP autocomplete. JIT definitely improved things [especially on my x86 machine], but I'm still unhappy with the slowness. Outside of LSP it's incredibly speedy.
It actually does; support for async io has been there for ages. If you've ever compiled or run git push or run an external command like M-! sleep 10 & RET from Emacs, that's using async io. For things that end up calling an external command like that, the code will typically use `start-process` or `make-process`. For network io, there is `url-retrieve` with callbacks. For tasks that need to be run via emacs-lisp (e.g. sending emails, compiling elisp), there is John Wiegley's `async` library.
However, lots of packages simply don't use these affordances.
Also, for LSP, there's additional challenges since lots of json needs parsing for each request, but IIUC Emacs can't currently process the messages to/from the server while the UI thread is busy (the LSP server can do lots of work while UI is busy, but the communication is stalled until UI is done). Though it seems things will be improving there, hopefully this'll get upstreamed soon: https://www.reddit.com/r/emacs/comments/ymrkyn/async_nonbloc...
I had the same issues with LSP and I switched to eglot and it's much less sluggish for me. I don't know why that is or if it's a general solution but worth giving a shot as eglot is built in I think in the newer versions.
Spacemacs comes with evil-mode (emacs vim emulator) default and it's very feature rich, so I think for someone coming from vim it'd be ideal. I personally use spacemacs with evil-mode disabled (I don't do vim, never did, have no plans on learning it) and I absolutely love. It's just a bit unstable but overall great operating sys... ehm editor.
> I’ve fallen into something of a cycle of adding packages until I’m annoyed by things breaking
Dependency hell is very real and doesn't just affect Emacs. I simply version my entire Emacs (back since when Mercurial was a thing) config so any SNAFU that'd happen when I try a new package is one checkout away: I just reset to the last known good state and call it a day (for that package).
I've got about 3 000 lines of custom elisp code and everything works fine.
I don't disagree that bare Emacs and Elpa works well. Now that use-package is shipped with Emacs I eventually switched to it. Took a while but it's been smooth sailing.
I really heartedly recommend people to version their entire Emacs config in Git. Some shall go further and recommend to version your entire home directory for that matters. Or to use something like Nix.
I'd say any of these options is fine as long as "going back to the last working config" is one command away.
If you start using an extendible tool like Emacs for something and put in the effort to learn it's key bindings, how it works, it's language if it has one etc it becomes increasingly annoying and a chore to use other software.
You either start trying to cram every possible task into that tool or try to find other software that was developed specifically for users of that tool (eg: Nyxt and Qutebrowser).
It feels like a very natural thing to do at the time even if it sometimes results in subpar results like what you're describing. I've personally declared "Emacs bankruptcy" multiple times and even go through periods of completely changing workflows if I get annoyed enough.
I mean, this is true of all computing? My phone works rather well, and then I see all of the crap family adds to their phone. Then I'm shocked it works.
Same for computers at large. Let parents or kids install whatever, and expect woes.
Emacs can feel worse, in this regard; but, I for one love how open it is to extend. Literally a defun and you've extended it.
> Emacs can feel worse, in this regard; but, I for one love how open it is to extend. Literally a defun and you've extended it.
Which is how all (or at least most) of our computing systems should work. The inability to easily extend programs is what leads to the "need" to replace them so often with other programs that satisfy unmet needs or capabilities. Which ends up mostly creating churn, not value or utility.
> Emacs Lisp is probably the worst language for "programming in the large". (After Javascript.)
But unlike JavaScript (and Node.js), I don't know of anyone who uses Emacs out of the belief that Emacs Lisp is a language with which they should be building large-scale applications. It is strictly a client-side language and it is used as such.
In fact, Emacs Lisp is actually a pretty good client-side language. Not that it is perfect, but I find it more enjoyable to use than JavaScript.
I strongly disagree, it is just a lisp. It seems very suited for the job, is there any other competitor who has stood the test of time (I dont just mean this years fashion chrome wrapped editor) with as many extensions ?
Strongly disagree. With lexical bindings it's on par with contemporary strongly typed dynamic languages like python. It does even have fancy pattern matching with pcase library built in, plus lots of fancy stuff for editing like thing-at-point.
I assume it's the typical corporate situation: when you have to work together on a codebase that's too big for one person to get a mental overview of. And unlike with a codebase you develop in your free time, you have no real control of who you have to work with.
I'm curious what the criteria for this is? And also happy to note elisp is quite effective at extending emacs. Regardless of what it is lacking at large. :)
But this is odd. When has the lack of namespaces caused a problem to you? When has cl-defstruct or eieio been insufficient to give you what you wanted out of OOP paradigms? I feel like your examples, and multithreading, are just programmers going off surface appearances of modern features and judging before using.
> When has the lack of namespaces caused a problem to you?
I can't imagine the maintenance of a Lisp system where several ten thousand names are flat in one namespace. For example: there is no way to browse those just looking at names with prefix parts. Textual name prefixes are a poor substitute for a proper "first class" namespace system. What parts of the symbol name are actually a prefix?
"CL-CADDAR" -> that means that I can't load any CL source code into Emacs, because every operator has been renamed. What? There is a subset of Common Lisp in GNU Emacs, but with all operators and variables renamed?
40 years ago Zmacs and the surrounding libraries on a Lisp Machine were already better structured.
> cl-defstruct or eieio
It's one thing to have features in a language as add-ons and actually having them integrated into the core. The whole optional CL feature & naming debacle shows that there are serious disconnects between developers and the leaders.
> It's one thing to have features in a language as add-ons and actually having them integrated into the core. The whole optional CL feature & naming debacle shows that there are serious disconnects between developers and the leaders.
Not really sure what you mean. These are not "add-ons" any more than standard libraries are add-ons to other languages. They are fully integrated into core of Emacs, and has been that way for decades already. The naming situation might imply otherwise, but "cl-" namespace is by no means a second class citizen and I think there are practical value in keeping that naming scheme. In any case they are pervasively used both internally and in the community.
"Due to restrictions in the Emacs Lisp language, CLOS cannot be completely supported ... EIEO does not support method dispatch for built-in types and multiple arguments types. In other words, method dispatch only looks at the first argument, and this one must be an EIEIO type."
does not look like it is fully integrated into the core.
> I think there are practical value in keeping that naming scheme
To prohibit reuse of existing code? Where is the practical value? If Emacs Lisp had a namespace mechanism, this would be no topic and nobody would argue keeping a strange naming scheme, where operators are named incompatibly to the language where they were coming from.
Let's define most of Scheme features, but rename all the operators. That's really really strange to argue... I makes the reuse of millions of lines of existing code impossible from day zero.
I've never even imagined copy-pasting straight Common Lisp code into an Emacs Lisp file. And I have to say:
1. The implementations of many functions are subtly different anyway, much like you can't expect Ruby's string join to work the same as Python's string join, down to an identical argument order and everything. That would be crazy to expect, right? You also can't do that kind of thing between Scheme and Common Lisp for what that's worth.
2. Even if you wanted to do this, the name of the function would be the easiest part of the migration: it takes one round of search-and-replace. So the namespacing is not the problem, and it's barely a problem at all.
I'm not really understanding you, maybe. Why would you expect Elisp to be able to run CLisp code verbatim? And why would you ding a language for its inability to fulfil such an uncommon use case?
> I've never even imagined copy-pasting straight Common Lisp code into an Emacs Lisp file.
Just go into a different namespace and load the code. The Lisp Machine I use has several different dialects of Lisp in one image. I can tell what dialect to use and it reads and evals code from that dialect. I can have two REPLs for different Lisps running side by side in one Lisp world, where I can call all operators from all other dialects.
That's basically also what was imagined for a GUILE-based GNU Emacs: it would run all of Emacs Lisp, but would also additionally understand Scheme.
> You also can't do that kind of thing between Scheme and Common Lisp for what that's worth.
Sure I can. Here I have loaded SCHEME into Common Lisp. The namespace is called SCHEME.
Now I switch over to the SCHEME namespace, where I can use the SCHEME operators like DEFINE without prefix:
CL-USER 10 > (in-package "SCHEME")
#<The SCHEME package, 774/1024 internal, 0/16 external>
SCHEME 11 > (foo1 20)
42
SCHEME 12 > (define (foo2 a b) (+ a b 22))
foo2 defined.
SCHEME 13 > (foo2 9 11)
42
> the name of the function would be the easiest part of the migration: it takes one round of search-and-replace. So the namespacing is not the problem, and it's barely a problem at all.
I'm not just talking about migrating code by converting it. I'm also talking about using the same code from one file.
> And why would you ding a language for its inability to fulfil such an uncommon use case?
It's only uncommon because you are not used to it. In earlier times even very complex source code was shareable between similar Lisp dialects.
If one adds to a Lisp lots of operators from a slightly different dialect, then it would be useful to do it in such a way that the dialect is integrated in a way that original source code written in that dialect can be shared with only a minimum of work.
Namespaces is an odd one. In general, I've seen more woes from junior programmers over optimizing for "private visibility" than I have noticed the benefits. I can't claim there have been no benefits, so I cede it could be confirmation bias on my part.
Still, I don't want to just turn to nitpicking the examples. I asked, you gave. I'll think on those some.
I stand by my assertion that the abstractions are good for what emacs needs. As evidenced by how well it does keep up, all told. Does it do as well as a staffed resource to build some resources? Probably not. More, it is unlikely to ever be able to make a feature that nothing else can do. By virtue of it being open. If something is amazing from it, others can emulate it.
But, the amount of synergy between modules speaks volumes. Tramp alone is quite amazing at how many modes "just work" with it. With no prior planning on having to expose internals or special methods.
I also confess I expected threading to be mentioned. Another thing which I have seen cause as many errors as it typically helps. Effectively the "goto" of application development. Often best avoided, but also often required.
My impression has been that emacs itself does fine with multiple processes. As seen by the compilation buffer being fine. So, if you setup a sentinel and do the process buffer technique, things can be done. Most people lament the lack of threads, though. More, I think most people do not want to build the necessary stuff for a process buffer to help.
Happy to know where I'm mistaken there. And I've certainly seen places where a blocking call can be annoying. Usually creeps up into a place that was fine at first. Org mode source execution is a good one. For the vast majority of stuff I do in those, I'm fine that it blocks while it gives me the results. Then I'll kick off one block that I should have added the async flag to, but just didn't.
Right. I know if you don't do the process buffer code, you can freeze things. And I can fully cede that doing that for elisp is weird. Same idea in a sly buffer, though, is fine.
Edit: For amusement, I was trying to see how bad it could be, so I made a loop to get the 90000th fib. Which, wasn't enough to see here. Hard to really appreciate how fast computers have become.
sly is easier, there the computation is done by a remote Common Lisp. But the danger may be long running output operations, unless they explicitly give up control for other (possibly green) threads.
But in a Lisp application to not be responsive at all is kind of rare. Most Lisp application runtimes will be able to process interrupts and/or switch "green threads" or "native threads".
every single game with 'mods' has the same issues that the vast majority of extensible applications have.
the core developers (hopefully) care and understand about the cost of a cycle, whereas the mod/extension developers tend to care only about how their addition works and expresses itself to the user.
the mod/extension developers (generally, not in the case of foss projects) usually lack the scope to understand how their coding decisions affect the rest of the code base, or in the worst cases they lack the understanding needed to optimize something to the point of usability -- so they achieve their small purpose by any means possible, often times in fairly brutish manner, which kills app performance all together.
Anecdote from this morning: I was taking notes on a technical book in a field I have only a little experience with, and came across a lot of words that I wanted the definition of. At first I opened wiktionary in my browser, but then I thought it'd be nice to have everything in Emacs, after which I used `M-x eww`, `!wikt <term>`. Then on a whim I tried `M-x dictionary`, and lo and behold Emacs has a built in dictionary, which you can even install new dictionaries in and search across. The default dictionary wasn't perfect, with a few terms not existing, but it's hard to beat the convenience for the 95% case. As a bonus, it defaults to searching the word under your cursor.
The point here is less "hey, Emacs has a dictionary!" (I'm sure many/most editors do!), more "hey, Emacs has a lot of use cases built in and they're easily discoverable." It's a great platform with a lot of care put into it over the years by different people, and if you come to it with the perspective of "it's just an editor" you'll be missing out.
I know the basics of Emacs as an editor, and I understand that it is possible to use Lisp to extend it, but I have not come in contact with a good resource to teach me the fundamentals of how to do so. I know a bit of Lisp, I am more curious about how to expose the existing interfaces (API), where and what to look for. Does anybody have any suggestions? I like learning more by seeing somebody do it than by reading reference documentation if that helps.
The Emacs Lisp Reference Manual is the obvious resource. It also comes with Emacs so once you are comfortable with the Info reader you can have it at your fingertips at all times. https://www.gnu.org/software/emacs/manual/elisp.html
Emacs also has comprehensive and high quality docstrings on functions and variables. I find them to be much more useful than in most other languages. You can very often get by just reading the docstrings.
And finally don't be afraid to look at the source. Bind find-function and find-variable to some convenient keys.
Start simple. Find a personal itch to scratch, write some interactive functions that you can bind to keys. Or a hook to make something work way you'd prefer.
Other comments talk about the source code. What's interesting is that if you have emacs + the source code on your machine, you can use find-function to jump to not only the lisp source of a function, but also drill down into compiled functions.
for instance, I did it for "(list" and found:
DEFUN ("list", Flist, Slist, 0, MANY, 0,
doc: /* Return a newly created list with specified arguments as elements.
Any number of arguments, even zero arguments, are allowed.
usage: (list &rest OBJECTS) */)
(ptrdiff_t nargs, Lisp_Object *args)
{
register Lisp_Object val;
val = Qnil;
...
If you like seeing how other people have extended Emacs, then I recommend reading the source code of existing Emacs extensions. Emacs comes bundled with more than a million lines of such code you could read, and there is another million or so available to download from the package archive. There really is no shortage of examples to choose from.
Also the Emacs Manual and the Emacs Lisp Manual, which come with Emacs, very thoroughly document the Emacs extension interfaces.
If you use Emacs and you are curious how something works, look up the function/command/keybinding with the built-in help. It will usually contain a link to the Emacs source code implementing it.
At least I have learned a lot from reading how these things fit together in the code, and occasionally replacing a definition entirely or creating advice around it.
It's a very easy environment to do so in, because the documentation is automatically linked to the relevant source code, so you never have to get stuck at something because you don't know what it does under the hood.
An excellent tutorial that takes exactly this approach (building up to a novel Emacs mode for NYT Crosswords, of all things) is the O'Reilly book "Writing GNU Emacs Extensions, by Bob Glickstein.
Over the course of my career I've moved from Emacs (in-terminal), to Spacemacs (emacs mode), to Spacemacs (vim mode), to Doom Emacs (vim mode), to neovim (in-terminal).
After a while of using both emacs and vim text editing, I found the vim way much easier for me. I used emacs with "evil mode" (vim keybindings) for a long time, but I wasn't using all of the other features the author here speaks about. So I found it easier to run Neovim alone instead of the extra complexity of getting emacs to behave like vim.
Did you customize Emacs much? Or add functionality, rather than just customize? I'm a long time vim/nvim user and as much as Lua brought to the party, I'm finding I want to add functionality, and that feels more appealing in Emacs.
Mostly just LSP integration. I didn't really feel the need to manage my email or filesystem with Emacs. Even git I prefer to use on the command line than use an editor/IDE plugin for.
Yeah same. I'll probably spend a some more time with Emacs, having fun toying around with it, and then realize all I really want is a fast, snappy editor. Then I'll be back to nvim. Wash-rinse-repeat every couple of years.
Nothing wrong with that. There was nothing wrong with emacs in vim mode — it functioned just fine. I'm familiar with lisp so it wasn't even hard to configure particularly, just not as easy as neovim for my particular use-case.
Emacs is fantastic, and yet it has to fight the uphill battle of "everything is a string". So even though emacs is "much more than an editor", in the words of Voit, it is "not enough" (https://project-mage.org/emacs-is-not-enough).
I consider Emacs a framework for building (primarily) text-based applications. By default it comes with multiple applications, lots of building blocks and a very rich API.
are there plugins/add-ons to emacs for Java that lets a dev do the kind of refactoring available in eclipse or intellij? It seems emacs brings a lot of power to develop such tools with it, but are the tools there yet or am I stuck having to write every little thing on my own by having to master lisp?
I worked at a place where several people used a Jetbrains IDE and they loved them. We were doing web dev with Go and TS. So I asked one day what were the killer features that they liked so much and I don't remember what they listed but Emacs had all of it. So I would assume that applies for Java.
Emacs definitely doesn't have any of the advanced refactoring and code analysis features of a Jetbrains IDE. Now, these are all mostly niche features that you'd use maybe once a month, but when you do need them, they save huge amounts of time for large code bases.
Here are some examples:
- Extract class / method / function (takes a piece of code and converts it to a class/method/free-floating function, while detecting all context dependencies and turning them to parameters or fields; also generates the proper constructors to populate those fields; and calls the right constructors/methods passing those parameters from context)
- Extract parameter / field (takes a local variable and makes it a parameter/field, and identifies all callers to propagate a value)
- Versions of the previous extractions that can go through a deeper call stack, automatically propagating along all functions along the way; essentially identical to using the same thing repeatedly, but in a single step
- Data flow to/from here (takes a variable and tells you something like 'the value here is coming from this parameter, which was populated from that field, which is assigned to in these two places; in the first place, it is assigned from this IO function; in the second place it is set to the value of this parameter which is populated from this constant; for "from", it is doing the same, but for all downstream uses of this value)
Emacs definitely has those, in the same way that VSCode has them, ie via extensions. Emacs has LSP builtin now I believe, so these things are easier to setup
If you know of an Emacs extension that does these, I would be very happy to know about it. These days I'm programming 100% in Emacs for various reasons, so I looked quite a bit (though it's true that was a few years ago now, so maybe some have turned up).
LSP itself certainly doesn't support this, though they can probably be built on top of it with some effort. For that matter, I also don't think VSCode supports them, though I have used Emacs far far more than that.
> I don't remember what they listed but Emacs had all of it.
Of course Emacs has none of it. Through a combination of various extensions and plugins of wildly varying quality, and through increasingly arcane config files you can have some semblance of what an IDE offers, but definitely not even close to "all of it".
Of course Emacs has all of it. Through extensions, like VSCode or Atom or Sublime.
> through ... various extensions and plugins of wildly varying quality
Most Emacs plugins that I've seen are higher quality than most professional codebases I've seen.
> through increasingly arcane config files
Things are getting better not worse, so they are _decreasingly_ arcane config files. And Doom Emacs or Spacemacs make this dead simple to setup. This is no longer a valid issue.
I developed Java in Emacs using lsp-mode and the Eclipse Language Server, it worked quite well but there were some things it couldn’t do/I couldn’t figure out how to do (moving a class to a different package was something I never figured out). It definitely worked though, and I found I was productive.
I ended up moving to IntelliJ after being a long term Eclipse user and then using Emacs for about a year. I miss the keyboard-driven environment in Emacs and the more parsimonious keybindings, but IntelliJ is better as an IDE. Still use Magit though.
You don’t have to master Elisp at all to use Emacs, I have written very little Elisp. However I did use a distribution (Prelude, then Doom Emacs) which did a lot of the heavy lifting in setting up my initial environment - YMMV if you go in with vanilla Emacs and then edit your init.el until you find a working configuration for your needs.
Here's one good reason: unlike most "IDEs", Emacs has been around and it will stick around.
When I started programming, Turbo Pascal was all the rage, I then used Borland C/C++ IDEs. I saw various incarnations of Microsoft's Visual Studio come and go, get redone and rewritten. Every microcontroller vendor seems to try to ship their own IDE for some reason. All these IDEs come and go, and your customizations (or extensions) are lost.
In that same time, Emacs has stayed, and while it is being actively developed all the time, you can have a single IDE that works over a time span of 25 years or more. Parts of my init.el (Emacs initialization file) are from 1993.
* it's much, much more lightweight than IDEs like IntelliJ and VSCode.
* it supports every obscure language I like to try, not just the popular ones the IDE vendor has interest in supporting (third-party plugins for other IDEs tend to be pretty poor, IMO), and adding your own "macros" for new languages is very easy.
If you have a very powerful laptop with a lot of RAM and don't mind only using that for programming, and you only use languages that are well supported for your IDEs, then I don't think you would like emacs. Otherwise, it's great to have it!
> it supports every obscure language I like to try
For syntax highlighting and other syntax related features yes. But I often felt that it was a pain to get more involved features like debugging to work. I don't remember what the story was for automatic refactoring. I don't remember that working.
IDEs make sense when you have one or a few large year-long coding projects. If a lot of your time is spent focussing on Ops and Sec, jumping between directories all over the file system and making little changes here and there, firing up an IDE, configuring it and navigating projects is not efficient. I use a different editor for small quick edits and dealing with large projects that need building and all sorts of tooling set up.
Easy usage over SSH and on battery-powered laptops, etc.
Like I learnt vi originally because it was the only text editor on an air-gapped machine (since it had to connect to loads of obscure equipment) used for setting up psychology experiments in a lab I was an intern in.
I then used it on an Intel Atom 11" netbook for years as a student (I could only have one app open on a workspace at a time - everything had to be full-screen).
And then used it loads over SSH when working with a remote desktop and build server at a FAANG.
Both Emacs and Vim are so versatile in that respect.
I do almost all my coding over ssh and it takes about 5 mins to set up emacs by installing packages and copying the config file. I tried VScode and Pycharm multiple times and I kept getting errors so I switched back to emacs.
> They basically "live" within Emacs only. They've added another abstraction layer on top of their classic operating system. This does provide great abilities whose benefits can't be understood by most people unfortunately.
I'd be curious to know what are these benefits. I traditionally prefer specialized tools for different purposes, so would be curious to know what others prefer about the Emacs-only life :)
Emacs is more like an ecosystem, within it you absolutely can and do have specialised tools for different purposes.
The benefit is that, traditional process based boundary forces you to use IPC mechanism for combining different tools, e.g. unix pipes. This is fine for many things, but your communication medium is usually still a stream of bytes with no structure. Unless what you want can be achieved by simply combining two or more tools, when you write bespoke tools, you end up doing serialising and deserialising data over and over again just to send through pipe.
In Emacs all "plugins" reside in same process space, so they aren't handicapped by requirement of structure-less IPC. You can simply write functions that work on each other's structured data. This is more pronounced in case of TUIs such as ncurses programs (as opposed to CLI programs), they can't be composed or combined with each other easily, but in Emacs that's not a problem because underlying data layer remains accessible all the same. Overall, the mechanism of composing multiple specialised tools to produce gestalt effect is arguably more streamlined in Emacs, not less.
On the flip side, this homogenous ecosystem comes at the expense of not having an array of languages at your disposal like in unix. But tbh elisp is a fine general purpose language, so that's not as big a problem as you might think. There are other concerns like security, plugins being able to peek into another's data is one of seminal reasons why OS process as boundary is a thing.
Back in the 80s and 90s people did not often distinguish between app platforms and operating systems, because back then there were no widely-used portable app platforms like Java or the Web.
Nowadays though, with a few popular app platforms running on numerous operating systems, there is a clear distinction between OS and app platform.
Emacs is an app platform for client-side applications.
On the other hand these days[1] we run OSs within OSs via virtualization. And we can run apps on bare or virtualized metal without an OS. So the I think that the distinction between app platform and OS is almost non-existent. Given virtualized hardware, even OS as an hardware abstraction client is not so clear cut.
I'll say it: the browser is an OS, sue me.
[1] we always could of course, it was just not mainstream
If anything, the opposite is true: those who try to diminish Emacs point out the absurdity of referring to it as an editor. To them, what has been accomplished through elisp is more of an indicator of a lack of focus or of bloat than it is of Emacs versatility.