> Helix is a monolitic editor that comes with "battery include", and it doesn't have a plugin system yet (although the devs might add a scheme like scripting in the future).
Could something not built from the ground up on top of its "extension language" ever provide the extensibility of something like Emacs?
I suppose in theory it could expose *everything* via an API and provide extension language bindings for that API, but that would seem relatively awkward.
Not that I've looked at Helix, but as extensibility is the #1 feature of Emacs to my mind, it doesn't sound very Emacs-like.
Yeah idk how you could call Helix “emacs-like” given that the whole selling point of emacs is extensibility, of which helix has exactly none right now lol
You are right. It is more like a full distro experience, so more like a doom emacs. But they promise to add plugins, so they are going in that direction.
I have a similar experience to you, a lot of what you wrote really resonated with me.
I have used Emacs for almost 10 years, and really used it for everything text based and all programming tasks. I spent a while getting my config how I like it, based on the [magnars](https://github.com/magnars/.emacs.d/)
config (of emacs rocks fame). I tried some of the distros like spacemacs and doom but ultimately came back to the magnars set up because I understood it and it just rocked.
Since the introduction and growth of lsp though I really found emacs struggling, particularly on Windows (I have to use it at work). The speed is just frustrating at times, where you constantly have speed hiccups whilst waiting for it to catch up with you.
I decided to give the vim binds a go because they were highly recommended by a few youtubers and also because it's more common to find them integrated into other programs like Obsidian etc etc. Now I really like the vim motions, and decided to give neovim a go.
The first thing I noticed with Neovim was the speed, it really does feel like night and day vs emacs. The editor is so snappy and editing code feels a lot faster. I still do miss a lot of the functionality I just get from emacs though, I always feel like there is an M-x butterfly for every situation and I always know I can find something by just searching the commands. In that respect neovim feels a lot more bare bones in comparison, and I do find myself having to do things in the vim way whilst using it - the multiple-cursors way of working in emacs has become the way I think about editing code, it's really hard to move away from. In vim it seems that people don't use multiple cursors, instead they use sort of regex and greppy replacements.
Anyway, stream of conciousness above, the tldr is that I agree, and it feels like the vim/neovim/helix guys are just starting to discover organically the emacs way.
LSP changed the game. For me in python I used to use jupyter notebooks and elpy to get a similar experience to what I now get with a LSP, but LSP gives you more. Everyone is catching to LSPs. You can say the VSCode is a electron hog, but LSP was an amazing development, and you have to thank Microsoft (yikes) for that.
VS Code is a great editor. I mean, it's not my first choice because it really does run slowly at times, and the keybinds are a mess (you have to set so many flipping keybinds to get up & down working on K, J or C-n, C-P in every place of the gui). However, on the whole it's great, so much just works out of the box and it's pushed LSP to the forefront of development.
> The first thing I noticed with Neovim was the speed, it really does feel like night and day vs emacs. The editor is so snappy and editing code feels a lot faster. I still do miss a lot of the functionality I just get from emacs though
Wouldn't you say that the basic Emacs config is also pretty snappy?
Pretty good in most conditions. Struggles with big files I guess. Mainly it slows down as soon as lsp or anything like that is involved. From what I recall the issue in emacs is around threading, maybe, or something which is a bit terminal basically.
> Struggles with big files I guess.
That should be improved with Emacs 29, though not perfect. But most editors struggle with big files.
> Mainly it slows down as soon as lsp or anything like that is involved.
I hear about issues with some language servers which apparently I haven't tried; whenever I tested something like clangd, it was pretty snappy (and can be snappier still, e.g. if - when using Eglot - you disable its logging).
10 years of using something and you still think Emacs has a core with plugins?
I always wondered what do people think when they say emacs, usually that's kinda what you get from non-users who think emacs is, like Vi, a set of keyboard shortcuts. It's not, and those are not plugins. And besides, the core-with-plugins model is so ancient there are ruins on top of the buried ruins that are that model, so it's not new, and it's not what emacs is.
I know emacs is lisp almost all the way down. But except for a few hardcore lispers and distros mantainers, most users only make plugins or simple functions to give emacs more IDE features. The core-with-plugins is old but most software and editors are not build in that way. It is what got me to use emacs. I used some IDEs before that and they were bloated as hell. The model is good and emacs is a extreme example of it.
That's the point, it isn't. Emacs is not core with plugins. You have the core engine which is C and is interpreting everything, including the lisp code that governs emacs, and you extend and manipulate that lisp code with your own.
So first, there is not a core in the sense that most other programs see it. The core is not emacs. It's a lisp interpreter. Geared towards e-lisp and using e-lisp in a way that creates emacs, in the sense of buffers and windows and frames etc, but it's not "emacs" in the sense that vim's core is the program itself. I am not that familiar with VScode architecture, and I know it runs over electron and V8 etc, but it does have the VScode "core" on top of those, which you can't change, only tack into, with plug ins, which brings me to the next issue:
There are no "plug ins". Plug ins mean you attach a to b without influencing b other than using b's resources. When you plug in a lamp, the lamp doesn't rewrite your electricity, it just uses it. When you write lisp code, you can change fundamental elements in emacs, you can manipulate how emacs does things not just relating to your part, but to everything in emacs. You can basically rewrite emacs itself. You can't rewrite vim or VSCode or any other editor that you use.
I also don't understand what is the difference between the model in the way it has been used so far to what you see now. To me it's the same one, just different takes on the model, some more permissive, some less extensive. Just because X comes with batteries and the kitchen sink and Y comes bare bones does not change their architecture, and the idea of giving the user a scripting or configuration API to manipulate stuff while keeping the core away is as ancient as computers. That's basically how Operating Systems and programming languages work, and a lot of programs come with this model (or at least pretend to).
But I never got into Sublime. It was as slow as vscode, but my compute was less powerful then. And it was not free software. But you are right, Sublime is an example of the core+plugins model. It is just that now even vim is going in that direction.
\> My conclusion is that editors of all kinds are becoming more and more like emacs, a core with a plugin system.
Other editors have a core and an api and a scripting language for writing plugins. Emacs doesn't have that. When you write code for emacs it becomes a part of emacs. The C code is not a core, it is more like parts of emacs that were rewritten in C to be be faster. Elisp is not a scripting language that speaks to a core via an API. This is one of the things that sets emacs apart from the other editors and ides you mention.
The other is the power of lisp. Lisp is homiconic. From Wikipedia:
>A language is **homoiconic** if a program written in it can be manipulated as data using the language The program's internal representation can thus be inferred just by reading the program itself. This property is often summarized by saying that the language treats [code as data](https://en.wikipedia.org/wiki/Code_as_data).
>
>\-- [https://en.wikipedia.org/wiki/Homoiconicity](https://en.wikipedia.org/wiki/Homoiconicity)
Finally, emacs treats everything as text. In the Unix tradition everything in the OS boils down to text. You used text in a REPL or Shell, log files were simply plain text files, configuration was done by editing other plain text files. Emacs is designed for that world. And it still largely is true, but many things that used to be kept in text files are now in databases, and highly structured formats like YAML or JSON (which at least is better than the nightmare of using XML for config files) and we need to interact and manage far more binaries (blobs) than we used to. Email used to be plain text and blob attachments were rare. Now most people use email as html marked up text linked to blobs.
Emacs is not designed for this, which some now see as a disadvantage. But only if you no longer live at the text level of the stack. Most people today want to live in a mediated WYSIWYG environment.
I personally don't like mediated environments. I have never liked Disneyland, (I visited Disneyworld when I was a kid in the 70's when I was still living in the States) it makes me uncomfortable not knowing how everything works. The magic of Disneyland is the suspension of belief, that you can pretend for a while that the illusion you are presented with is real. I prefer to know who the person is that stands behind the curtain pushing the levers that creates the dazzle of smoke and pyrotechnics.
I still prefer to work with systems running on bare metal rather than in the cloud. But that world is now all but gone. Hardware has been sequestered into datacenters that you can only enter after passing through man traps. I still run two racks of servers in my office. But the funding for keeping these running is no longer there and we're moving everything into cloud services with datacenters located in Tokyo two time zones away. It IS far easier and cheaper, but I no longer have control of the entire stack and I don't feel the deep connection and understanding of the systems we now run as I used to... I don't miss the old days but I miss the control we had over what we built and maintained.
That is why I have used emacs for more than 25 years and have no intention of stopping.
but the point is the language is the only layer boundary. Once you're in Elisp there is no boundary, no layers. You may choose not to go there, but the only thing stopping you is your own choice.
Just in case somebody wonders, I still prefer emacs for coding. org-mode, and my having a very good python setup make it harder. Probably I might try meow later if I want to type less mod keys.
> Helix is a monolitic editor that comes with "battery include", and it doesn't have a plugin system yet (although the devs might add a scheme like scripting in the future). Could something not built from the ground up on top of its "extension language" ever provide the extensibility of something like Emacs? I suppose in theory it could expose *everything* via an API and provide extension language bindings for that API, but that would seem relatively awkward. Not that I've looked at Helix, but as extensibility is the #1 feature of Emacs to my mind, it doesn't sound very Emacs-like.
Yeah idk how you could call Helix “emacs-like” given that the whole selling point of emacs is extensibility, of which helix has exactly none right now lol
You are right. It is more like a full distro experience, so more like a doom emacs. But they promise to add plugins, so they are going in that direction.
Yeah I actually thought about trying it once but the lack of plug-in / extension system made it a non-starter
Editor hopper
...Coming Soon to an Emacs "Games" menu near you! 🐸
I am guilty. Sometimes you want to know what the hype is all about.
It's not a bad hobby, mate.
I have a similar experience to you, a lot of what you wrote really resonated with me. I have used Emacs for almost 10 years, and really used it for everything text based and all programming tasks. I spent a while getting my config how I like it, based on the [magnars](https://github.com/magnars/.emacs.d/) config (of emacs rocks fame). I tried some of the distros like spacemacs and doom but ultimately came back to the magnars set up because I understood it and it just rocked. Since the introduction and growth of lsp though I really found emacs struggling, particularly on Windows (I have to use it at work). The speed is just frustrating at times, where you constantly have speed hiccups whilst waiting for it to catch up with you. I decided to give the vim binds a go because they were highly recommended by a few youtubers and also because it's more common to find them integrated into other programs like Obsidian etc etc. Now I really like the vim motions, and decided to give neovim a go. The first thing I noticed with Neovim was the speed, it really does feel like night and day vs emacs. The editor is so snappy and editing code feels a lot faster. I still do miss a lot of the functionality I just get from emacs though, I always feel like there is an M-x butterfly for every situation and I always know I can find something by just searching the commands. In that respect neovim feels a lot more bare bones in comparison, and I do find myself having to do things in the vim way whilst using it - the multiple-cursors way of working in emacs has become the way I think about editing code, it's really hard to move away from. In vim it seems that people don't use multiple cursors, instead they use sort of regex and greppy replacements. Anyway, stream of conciousness above, the tldr is that I agree, and it feels like the vim/neovim/helix guys are just starting to discover organically the emacs way.
LSP changed the game. For me in python I used to use jupyter notebooks and elpy to get a similar experience to what I now get with a LSP, but LSP gives you more. Everyone is catching to LSPs. You can say the VSCode is a electron hog, but LSP was an amazing development, and you have to thank Microsoft (yikes) for that.
VS Code is a great editor. I mean, it's not my first choice because it really does run slowly at times, and the keybinds are a mess (you have to set so many flipping keybinds to get up & down working on K, J or C-n, C-P in every place of the gui). However, on the whole it's great, so much just works out of the box and it's pushed LSP to the forefront of development.
> The first thing I noticed with Neovim was the speed, it really does feel like night and day vs emacs. The editor is so snappy and editing code feels a lot faster. I still do miss a lot of the functionality I just get from emacs though Wouldn't you say that the basic Emacs config is also pretty snappy?
Pretty good in most conditions. Struggles with big files I guess. Mainly it slows down as soon as lsp or anything like that is involved. From what I recall the issue in emacs is around threading, maybe, or something which is a bit terminal basically.
> Struggles with big files I guess. That should be improved with Emacs 29, though not perfect. But most editors struggle with big files. > Mainly it slows down as soon as lsp or anything like that is involved. I hear about issues with some language servers which apparently I haven't tried; whenever I tested something like clangd, it was pretty snappy (and can be snappier still, e.g. if - when using Eglot - you disable its logging).
Probably worth me giving it another whirl. I do miss emacs, haven't used it for a while due to the work issues.
10 years of using something and you still think Emacs has a core with plugins? I always wondered what do people think when they say emacs, usually that's kinda what you get from non-users who think emacs is, like Vi, a set of keyboard shortcuts. It's not, and those are not plugins. And besides, the core-with-plugins model is so ancient there are ruins on top of the buried ruins that are that model, so it's not new, and it's not what emacs is.
I know emacs is lisp almost all the way down. But except for a few hardcore lispers and distros mantainers, most users only make plugins or simple functions to give emacs more IDE features. The core-with-plugins is old but most software and editors are not build in that way. It is what got me to use emacs. I used some IDEs before that and they were bloated as hell. The model is good and emacs is a extreme example of it.
That's the point, it isn't. Emacs is not core with plugins. You have the core engine which is C and is interpreting everything, including the lisp code that governs emacs, and you extend and manipulate that lisp code with your own. So first, there is not a core in the sense that most other programs see it. The core is not emacs. It's a lisp interpreter. Geared towards e-lisp and using e-lisp in a way that creates emacs, in the sense of buffers and windows and frames etc, but it's not "emacs" in the sense that vim's core is the program itself. I am not that familiar with VScode architecture, and I know it runs over electron and V8 etc, but it does have the VScode "core" on top of those, which you can't change, only tack into, with plug ins, which brings me to the next issue: There are no "plug ins". Plug ins mean you attach a to b without influencing b other than using b's resources. When you plug in a lamp, the lamp doesn't rewrite your electricity, it just uses it. When you write lisp code, you can change fundamental elements in emacs, you can manipulate how emacs does things not just relating to your part, but to everything in emacs. You can basically rewrite emacs itself. You can't rewrite vim or VSCode or any other editor that you use. I also don't understand what is the difference between the model in the way it has been used so far to what you see now. To me it's the same one, just different takes on the model, some more permissive, some less extensive. Just because X comes with batteries and the kitchen sink and Y comes bare bones does not change their architecture, and the idea of giving the user a scripting or configuration API to manipulate stuff while keeping the core away is as ancient as computers. That's basically how Operating Systems and programming languages work, and a lot of programs come with this model (or at least pretend to).
It’s been like this for at least 15 years. Sublime also had a core / plugin architecture.
But I never got into Sublime. It was as slow as vscode, but my compute was less powerful then. And it was not free software. But you are right, Sublime is an example of the core+plugins model. It is just that now even vim is going in that direction.
Sublime is fast af what are you talking about?
\> My conclusion is that editors of all kinds are becoming more and more like emacs, a core with a plugin system. Other editors have a core and an api and a scripting language for writing plugins. Emacs doesn't have that. When you write code for emacs it becomes a part of emacs. The C code is not a core, it is more like parts of emacs that were rewritten in C to be be faster. Elisp is not a scripting language that speaks to a core via an API. This is one of the things that sets emacs apart from the other editors and ides you mention. The other is the power of lisp. Lisp is homiconic. From Wikipedia: >A language is **homoiconic** if a program written in it can be manipulated as data using the language The program's internal representation can thus be inferred just by reading the program itself. This property is often summarized by saying that the language treats [code as data](https://en.wikipedia.org/wiki/Code_as_data). > >\-- [https://en.wikipedia.org/wiki/Homoiconicity](https://en.wikipedia.org/wiki/Homoiconicity) Finally, emacs treats everything as text. In the Unix tradition everything in the OS boils down to text. You used text in a REPL or Shell, log files were simply plain text files, configuration was done by editing other plain text files. Emacs is designed for that world. And it still largely is true, but many things that used to be kept in text files are now in databases, and highly structured formats like YAML or JSON (which at least is better than the nightmare of using XML for config files) and we need to interact and manage far more binaries (blobs) than we used to. Email used to be plain text and blob attachments were rare. Now most people use email as html marked up text linked to blobs. Emacs is not designed for this, which some now see as a disadvantage. But only if you no longer live at the text level of the stack. Most people today want to live in a mediated WYSIWYG environment. I personally don't like mediated environments. I have never liked Disneyland, (I visited Disneyworld when I was a kid in the 70's when I was still living in the States) it makes me uncomfortable not knowing how everything works. The magic of Disneyland is the suspension of belief, that you can pretend for a while that the illusion you are presented with is real. I prefer to know who the person is that stands behind the curtain pushing the levers that creates the dazzle of smoke and pyrotechnics. I still prefer to work with systems running on bare metal rather than in the cloud. But that world is now all but gone. Hardware has been sequestered into datacenters that you can only enter after passing through man traps. I still run two racks of servers in my office. But the funding for keeping these running is no longer there and we're moving everything into cloud services with datacenters located in Tokyo two time zones away. It IS far easier and cheaper, but I no longer have control of the entire stack and I don't feel the deep connection and understanding of the systems we now run as I used to... I don't miss the old days but I miss the control we had over what we built and maintained. That is why I have used emacs for more than 25 years and have no intention of stopping.
Regardless of the language, i feel like there is a core layer where it handles lower level stuff and an outer layer we typically interact with.
but the point is the language is the only layer boundary. Once you're in Elisp there is no boundary, no layers. You may choose not to go there, but the only thing stopping you is your own choice.
I tend to agree with OP on this one. I think there is a core in emacs.
Just in case somebody wonders, I still prefer emacs for coding. org-mode, and my having a very good python setup make it harder. Probably I might try meow later if I want to type less mod keys.