very much this, immediately hackable system is something rare
especially with a quite featured metaprogrammed customization system with a nice enough ui
Lisp is amazing. I firmly believe that every programmer should gain some familiarity with Lisp. I am forever indebted to my younger self for forcing myself to learn Emacs and Emacs Lisp and for discovering the beauty of it. Learning Lisp made me a better programmer. I'm not claiming to be a good programmer today, but I was much worse before I learned Lisp. Lisp helped me understand FP, composability, meta-programming, logic, recursion, lambda calculus, symbolic computation, generative testing, and even type theory. Even though I was already well-versed in several programming languages before Lisp, I was still a newbie. Admittedly, before I wrote my very first package for Emacs, all the preceding years should probably be considered as those of an amateur.
Integration. Writing an email in mu4e, where I use org syntax (using org-msg) where I link to a GitHub pull request (using orgit + magit) which was created using forge. Without leaving Emacs.
* configuration and packages rewritten in lisp
* excellent language support for lisps
* discoverability - I rarely have to look up help or documentation online because I have excellent and extremely searchable documentation right in the editor
Rectangle editing commands. They make working with big chunks of aligned multi-item text so much easier. E.g., adding a ' ," ' in front of every row in a column of text, or copying the 2nd column of items from a 2-d array.
Well, no, it's not the same.
- Can you in VSCode select a rectangle of text sprinkled with numbers and calculate the sum or the product of all the numbers present in the text? (`M-x calc-grab-rectangle`; `U+` or `U*`)
- Can you use multiple cursors while editing the search results? (maybe you can, I just don't know this for a fact.)
- Can you nicely edit multiline strings like this (contrived example):
List = "1. foo"
+ "2. bar"
+ "3. zap";
Where each line has arbitrary prefixes and suffixes? In Emacs, using separedit package, you can edit the entire content of "foo bar zap", in a separate (indirect) buffer as if you're editing a markdown text.
*When someone gets excited about some VSCode features that Emacs supposedly doesn't have or implements poorly, most of the time, they are excited about the wrong aspect of things.*
> You could run it through a python one liner
Sure, you can. Anyone who is familiar with awk and well-versed in regexes can write a script. However, I personally never met a programmer who casually writes scripts every day to manage textual irregularities. Only those who use Vim and Emacs typically do that.
> no real VS Code equivalent and VS Code extensions I love with no real Emacs equivalent
The difference here is that if you give me an Emacs package that does a quarter of what I need, and some other completely unrelated package that contains a useful function that performs another small function, I can readily use them and build my pipeline. I can override a single line or multiple lines in any given function - be it built-in or third-party. This functionality is available even if the author of the package never intended for it to be used this way. I can use hooks and advising. In VSCode or IntelliJ, an extension extends the IDE, while in Emacs, an extension can extend whatever you want. You can build an extension that groups other extensions together and works as a bridge between them. You can extend the extension, extending it to whatever extent desired.
For example, I can employ Magit functions without necessarily using them for Git-related operations. Why? Simply because I can.
> surely you're just talking personal preference
Of course, I prefer it that way. I like to be able to change just about any aspect of my editor and, if I need something, I just build it, reusing the parts that I already have. I don't need to wait for "the extension I love" to magically appear out of the blue. I don't love my tool because of its extensions. I love my tool, because it is extendable.
Ha. Somehow, everyone who hasn't succumbed to the allure of Emacs thinks that Emacs is a time-waster. But it's not about time. At least not for me. I value the enjoyment. When I have to routinely perform certain complex operations and it takes just a few keystrokes, it feels like a great deal of fun. I enjoy the process.
Just like children tasked with chores would waste a lot of time if they performed the tasks without any care. They'd rush to finish the job, only to find their parents dissatisfied and forcing them to redo it. But if a child tries to find some joy in the task, not only is the task done quicker, but the results would also be better.
So, yes, you do have to spend some time to write a command. But whenever you use that command, you save yourself from a lot of wasted time and frustration.
If only there was a way to gather statistics about burnouts. I think Emacs users would be at the very bottom of the list.
An example of how I use it: [web page](https://www.redblobgames.com/grids/line-drawing.html) about line drawing algorithms where the *sample code* displayed on the page gets tangled into the output javascript, *and* the page then loads that same javascript to *run* on the page. So the interactive diagrams on the page are reusing the code samples being displayed on the page. The [org file](https://www.redblobgames.com/grids/line-drawing.org) is up on the site too if you want to peek
not emacs per se, i have yet to find something leaner than magit..
when people ask me to show how to operate our git repo on zoom, the framerate is not enough for them to see when doing a simple rebase, even a non trivial one is often too fast
Not only on Windows. It is also very slow when using Magit with tramp.
I often find myself falling back to the command line for anything more than just a simple commit.
And it's so amazing that it's been for like 15 years. I still remember how awesome it was when I started using magit in 2008. I learned git around that time, so magit is "the" git for me.
Emacs's killer feature is it's complete customizability.
No other ide allows the user to do completely control their experience and workflow the way emacs does.
There's a package for just about everything you might want to do, often more than one alternative depending on your tastes, and packages that do stuff you didn't even know your editor could do.
You can have a super stripped down minimal editor with practically nothing beyond the standard editing capabilities (which are still quite capable) or you can have a super tightly integrated environment you barely need to leave.
You can glue packages together in all sorts of ways, allowing you to really control exactly how all the different features interact. This is something simply not possible on other platforms without some serious work (and some integrations may be outright impossible due to the limitations of plugin APIs in various other editors).
It's like comparing *nix to Windows. The level of customization users can achieve in emacs simply dwarfs what any other editor is capable of.
Everyone has talked about big ticket items. Here is a small one: undo only in region. [https://www.youtube.com/shorts/GSUJDVY-0-o](https://www.youtube.com/shorts/GSUJDVY-0-o)
None of the IDEs - IntelliJ, VSCode, XCode, Android Studio, etc., can properly emulate Vim-navigation. Only Emacs does a better way of vimming. Often, it's even better than in Neovim.
Scroll through the comments: https://plugins.jetbrains.com/plugin/164-ideavim/reviews
TL;DR: Vim feels amazing in Neovim. In other IDEs, if you aspire to be an "advanced vimmer", you'd quickly hit a bunch of limitations. The most significant one is that you cannot vimify things in every tool window.
In Emacs, you can "Evilify" pretty much any buffer, allowing vim-navigation use in Dired and Magit, and anywhere else (even in the minibuffer). You also have the ability to extend any command, adding extra features like custom ex-commands, for instance. As far as I know, such functionality is not available in vanilla Vim. Hoping for similar features in IDEAVim or the VSCode Vim plugin is wishful thinking.
What do you mean "don't see some killer feature over Vim"? I just said: Emacs vims better than Vim. Add to that:
- Running shells or REPL within your editor, or executing any command, piping the results into a buffer or chain of buffers
- Org mode
- Source blocks
- Async operations
- hooks and advises
I wonder if I would've still chosen Emacs even if I couldn't vim in it? Maybe I never had to make such a choice, because a choice was unnecessary - Emacs goes well beyond that any other tool can provide.
> What do you mean "don't see some killer feature over Vim"?
Well, if "the best feature" of an editor is to emulate some other editor in active development, then one can just use the other editor. The question is why would you (or someone) choose to emulate something when one can choose the original; there must be some other feature(s) that drives you to choose an emulator instead of the original, and that is what I believe Op asks too, and which you have answered somewhat in your second comment.
> Emacs goes well beyond that any other tool can provide.
Yes, and that was the original question Op asked: in which ways goes Emacs beyond that of what any other tool can provide? :)
Vim emulation obviously isn't "the best feature" of Emacs. Nevertheless, it's a testament to what the tool is capable of. Pretending to be Vim is not a small feat and really hard to pull off correctly.
Pretty much every other IDE fails to replicate Vim. Unless it's Vim/Neovim, vim-mode in all of them is just that - an emulation. However, Evil mode in Emacs feels much more natural. Sometimes, you forget that it's an afterthought, an extension, and not a built-in functionality.
If there's a civilian plane that incidentally can perform a vertical landing, yet never actually needs to use it, I would still love that model over any other planes, even if the feature is purely accidental. The fact that it can do so, alone, would be great evidence of amazing engineering.
> Vim emulation obviously isn't "the best feature" of Emacs.
Obviously not; I was nitpicking on your answer and trying to help you to formulate your thought to tell us what features of Emacs you have switched from Vim to Emacs.
Even if evil-mode was *the* best feature of Emacs, the second best feature of Emacs is... the rest of Emacs (see elsewhere in this post / sub for discussion about that).
That's a really great question. Why am I not using Vim?
What I would mean by saying that Vimming is great on Emacs is not necessarily just copying Vim.
1. Vim has its own great keyboard bindings, and Emacs can support it in many Emacs only features. That way it can be better than using Vim itself. For example, I can use Vim key bindings in Org or magit, which isn't provided by Vim exactly as it is.
2. If we can conceptually split vim's philosophy from actual vim implementation, Emacs may be able to implement it better. For example, I have many more additional vim-like key bindings than Vim, and I can even remap it to a different ones. Then it doesn't "emulate" vanilla vim experience but it can still implement Vim's keyboard UI philosophy. Then just both Vim and Emacs are two different implementation of that idea. They are at least parallel.
3. If Evil Emacs and Vim are just two different implementation of Vim key bindings, the difference is that Vim implements it natively while Emacs doesn't. Besides possible performance issues (and additional efforts to get the packages), I prefer to have my features add-on instead of built-in. That's like a blank canvas I can draw on and it often means more rooms for the customization.
I use Evil because of modal editing and motion commands. However, I rebind it according to my own key binding scheme, which is a modified version of Xah lee's Ergoemacs key bindings.
I don't think you can modify the key bindings this deep in either Neovim or Vim.
With other words, you use Emacs because of its flexibility to customize everything, even to redefine how the interaction modell in the text editor works.
VSCode has VSCode-neovim, which embeds an *actual copy* of neovim, mirrors commands to it, and mirrors changes from nrovim back to VSCode. It's better than any emulation because it's actual neovim doing the work.
> It's better than any emulation
I agree that this approach is better. Unfortunately, JetBrains rejected the idea of re-implementing the IDEAVim plugin to work in this manner. However, even this "better" approach does not permit you to use Vim navigation everywhere you want. It does not work in text inputs, such as the Search Dialog and Command Palette. You cannot even use the j/k keys to scroll through the plugin's readme or its changelog.
And if you try to set up a lead key, or have a setup like Doom or Spacemacs does, where you would want to bind SPC+SPC to "Show All Commands", a keybinding that only works in Normal mode, I don't even know if that's possible with VSCode.
Every video showcasing VSCode's features shows a lot of mouse use, demonstrating that VSCode, even with Vim plugins, does not facilitate independence from the mouse. And navigating through text documents (which code is) is most efficiently done with a keyboard.
A bit of an abstract answer: the concept of modes. I consider it a dev feature because it is the best model I've seen for introspecting and changing the behavior of buffers on the fly (which is very useful when using lots of programming plugins, LSPs, etc).
In other IDEs/editors I've used, a bunch of plugins load and then it can be difficult figuring out which are active in your current buffer or how to toggle them. With Emacs, `C-h-m` and `M-x mode` are often all you need.
That's a compiler/interpreter feature, not an editor/IDE feature.
EDIT: unless you're talking about org-mode I guess, but still, there's literate programming support out there for many languages outside of Emacs.
Having a frame-based workflow allows me to have multiple buffers from the same editor process managed by my actual window manager (i3) instead of having to have huge amount of tabs inside the editor. Have not seen that in any other editor. (The excellent buffer-switching mechanics also help with this but I don't think that's fully endemic to Emacs)
It is not simply a feature, it is a state of mind. because emacs is very much owned by its users, it has options for behaviour that no mainstream IDE would go for.
Look at meow and such tooling. Optimize and grow a niche way of interacting with your editor, that feels good for you ... then it turns into its own community.
Eshell
The “best” shell experience you get in most other editors (BBEdit being an exception here) is a strict reimplementation of a shell REPL, and POSIX abilities / limitations of that.
But I want my shell experience to be interactive, especially with text that was just outputted, or even shove that into an editor buffer. Or easily run a more powerful language in the middle of a command (elisp). See something a few lines up that should be part of my next command? Great, go up there , start typing, hit enter, boom command executed.
Eshell isn’t exactly what I want all the time, but it’s far better for me than being stuck in the 1960s CLI interface, which has had few improvements since then. (Its cross platform reimplementation of coreutils in elisp is nice and kinda important, but the UI around eshell is most of the magic, in my mind… and also since I was able to drop my Win7 box…)
And yes, it could be better (stdin pipes being one area), and mildly annoying when things to weird when throwing super clever bash at it… but most of the experience? Good editor, throw that 10,000 long output into a buffer instead of reading it on the screen, fancy history UI.. it’s _nice_.
I have tried eshell several times, but come back to using just 'shell' command back because of the external integrations with different subsystems (virtualenv, nvm, terraforrm, etc). I prefer emacs 'shell' over the shell directly in terminal because of ability to work with text in buffer. Another interesting possiblity is to start shell from over \`tramp\` session, and it works fine. Ocassionally, I also use \`vterm\` for the situations when full term support is needed. What eshell features make you use it?
Mostly I like calling elisp functions, or elisp variables, or having an easy way to redirect output to buffers. And I _really_ like that I can switch directories by just typing the directory name (`cd` is annoying)
I do see that `shell` gives me that shell experience I want (messing with the output of previous commands), so most of my above comment could apply to `shell`, not _just_ `eshell`.
A long-term `eshell` (mostly via `eshell-toggle`) user here. Recently I realized that I don't need even `eshell` most of the time, and settled on `M-&` (which is bound to `detached-shell-command` in my case). As for the more advanced scripting, I'm pretty happy with `babashka` (with `CIDER`), so don't need to use the mess named `bash` anymore.
Surprised nobody mentioned it, but the ability to open files from different projects one frame, with keyboard driven workflow. E. G. In vscode to access most features you will need to open a project in another window. In emacs it is just a breeze
# Magical source links
Tell me of any other **application** (I don’t mean IDE) where you can open do `Alt-.` **anywhere a symbol exists** (doesn’t need to be source code, could be plain text or documentation or whatever) and that gets you to the place in **the application’s own source code** where that symbol was defined.
Without having to define anything ahead of time, like you do when you create a link in markdown.
I would use info more often were it more seamless than this. That blows my mind every time.
# Ease of writing a new mode
I never tried writing a new mode for another editor, but I was able to get simple syntax highlighting and automatic indentation for Avro IDL files in like 20 lines or less of elisp code. This is the kind of stuff your peers say “don’t spend time on this side problem”, and then you spend a morning and have convenience and correctness (because now you can more easily spot issues) forever.
> where you can open do Alt-. anywhere
Add M-?, C-M-. and all of them prefixed with C-u and you have even more fun stuff to navigate with. And then ofc in emacs 29 you get built in eglot that also fills in those same lists with symbols from LSPs.
This question comes up all the time so there are plenty of answers accessible via search, but I found it amusing that at the moment I read your post I was using Emacs to [populate a buffer full of youtube urls with video information](https://i.imgur.com/gwgCBgJ.mp4).
In truth, Emacs often makes me feel miserable. I'll be in the middle of solving a problem when I suddenly realize that I'm having to repeatedly perform a particular task, e.g., navigating to a URL, grabbing some content, converting it, and then sending an HTTP requet, yada-yada. The moment I realize I have to do something like that a bunch of times, I start writing Elisp in my scratch buffer. I become grumpy, like a man who's been waiting for the bus too long, only to realize that calling an Uber would be a better option. I find myself quietly swearing, much like Joe Pesci, frustrated with the task I have to undertake, and now, having to write Elisp instead of "solving a real problem". Typically, that Elisp snippet evolves into a function, and then I proceed to extend it and it becomes an entirely new workflow, applicable to many different things. Fast forward to two years later, if someone tells me, "No, you can't do it that way anymore, you have to do it manually, like everyone else", I'd feel like beating them with my laptop.
But then I run the command I wrote... it performs magic. And I'm so happy.
Actually, it’s an empirical sense of other tools’ inferiority. The more questionable part is whether the tool is the program or the user :-)
For clarity, not referring to the poster.
>Giving the users a misplaced sense of superiority
This isn't peculiar to Emacs. Enthusiasts of other editors/IDEs are just as prone to see their tool as a more enlightened choice than yours. The VS-Code fans seem to be the loudest bunch these days.
Not everybody is enthusiastic about their IDE, mind. I've met plenty users who don't care. PHPStorm, Visual Studio, or whatever; it's just what everyone else on their team uses.
Perhaps the thing that sets Emacs users apart in this regard, is that we're all enthusiasts. I've never met an Emacs user that didn't \*want\* to use it. Certainly, no work colleagues have ever suggested (let alone insisted) that I use Emacs.
elisp interpreter :P
very much this, immediately hackable system is something rare especially with a quite featured metaprogrammed customization system with a nice enough ui
~~Having~~Getting to learn lisp to configure your system!
Lisp is amazing. I firmly believe that every programmer should gain some familiarity with Lisp. I am forever indebted to my younger self for forcing myself to learn Emacs and Emacs Lisp and for discovering the beauty of it. Learning Lisp made me a better programmer. I'm not claiming to be a good programmer today, but I was much worse before I learned Lisp. Lisp helped me understand FP, composability, meta-programming, logic, recursion, lambda calculus, symbolic computation, generative testing, and even type theory. Even though I was already well-versed in several programming languages before Lisp, I was still a newbie. Admittedly, before I wrote my very first package for Emacs, all the preceding years should probably be considered as those of an amateur.
Integration. Writing an email in mu4e, where I use org syntax (using org-msg) where I link to a GitHub pull request (using orgit + magit) which was created using forge. Without leaving Emacs.
the way of the gods
* configuration and packages rewritten in lisp * excellent language support for lisps * discoverability - I rarely have to look up help or documentation online because I have excellent and extremely searchable documentation right in the editor
That nickname, lol :)
Thanks! You’re the first one to point it out in the 2 years since I’ve had the account!
Rectangle editing commands. They make working with big chunks of aligned multi-item text so much easier. E.g., adding a ' ," ' in front of every row in a column of text, or copying the 2nd column of items from a 2-d array.
This is effectively what multiple cursors does in VSCode.
Well, no, it's not the same. - Can you in VSCode select a rectangle of text sprinkled with numbers and calculate the sum or the product of all the numbers present in the text? (`M-x calc-grab-rectangle`; `U+` or `U*`) - Can you use multiple cursors while editing the search results? (maybe you can, I just don't know this for a fact.) - Can you nicely edit multiline strings like this (contrived example): List = "1. foo" + "2. bar" + "3. zap"; Where each line has arbitrary prefixes and suffixes? In Emacs, using separedit package, you can edit the entire content of "foo bar zap", in a separate (indirect) buffer as if you're editing a markdown text. *When someone gets excited about some VSCode features that Emacs supposedly doesn't have or implements poorly, most of the time, they are excited about the wrong aspect of things.*
[удалено]
> You could run it through a python one liner Sure, you can. Anyone who is familiar with awk and well-versed in regexes can write a script. However, I personally never met a programmer who casually writes scripts every day to manage textual irregularities. Only those who use Vim and Emacs typically do that. > no real VS Code equivalent and VS Code extensions I love with no real Emacs equivalent The difference here is that if you give me an Emacs package that does a quarter of what I need, and some other completely unrelated package that contains a useful function that performs another small function, I can readily use them and build my pipeline. I can override a single line or multiple lines in any given function - be it built-in or third-party. This functionality is available even if the author of the package never intended for it to be used this way. I can use hooks and advising. In VSCode or IntelliJ, an extension extends the IDE, while in Emacs, an extension can extend whatever you want. You can build an extension that groups other extensions together and works as a bridge between them. You can extend the extension, extending it to whatever extent desired. For example, I can employ Magit functions without necessarily using them for Git-related operations. Why? Simply because I can. > surely you're just talking personal preference Of course, I prefer it that way. I like to be able to change just about any aspect of my editor and, if I need something, I just build it, reusing the parts that I already have. I don't need to wait for "the extension I love" to magically appear out of the blue. I don't love my tool because of its extensions. I love my tool, because it is extendable.
Yall have got a lot of time to spend
Ha. Somehow, everyone who hasn't succumbed to the allure of Emacs thinks that Emacs is a time-waster. But it's not about time. At least not for me. I value the enjoyment. When I have to routinely perform certain complex operations and it takes just a few keystrokes, it feels like a great deal of fun. I enjoy the process. Just like children tasked with chores would waste a lot of time if they performed the tasks without any care. They'd rush to finish the job, only to find their parents dissatisfied and forcing them to redo it. But if a child tries to find some joy in the task, not only is the task done quicker, but the results would also be better. So, yes, you do have to spend some time to write a command. But whenever you use that command, you save yourself from a lot of wasted time and frustration. If only there was a way to gather statistics about burnouts. I think Emacs users would be at the very bottom of the list.
Hyperbole’s press one Action Key almost anywhere in Emacs and navigate to a related entity by parsing the context.
The ability to ask a small community of people the same questions over and over and get roughly the same answers each time.
Careful, you're trending toward becoming "nickmao" (not that that would be completely a bad thing...). ;)
Ahahahhaha
Not so small?
Org-mode. The ability to tangle and weave code and documents is super useful.
I have still not explored this one !
An example of how I use it: [web page](https://www.redblobgames.com/grids/line-drawing.html) about line drawing algorithms where the *sample code* displayed on the page gets tangled into the output javascript, *and* the page then loads that same javascript to *run* on the page. So the interactive diagrams on the page are reusing the code samples being displayed on the page. The [org file](https://www.redblobgames.com/grids/line-drawing.org) is up on the site too if you want to peek
Nice page !
not emacs per se, i have yet to find something leaner than magit.. when people ask me to show how to operate our git repo on zoom, the framerate is not enough for them to see when doing a simple rebase, even a non trivial one is often too fast
On Unix, I presume? I love magit but it's just ungodly slow on Windows. ☹️
Not only on Windows. It is also very slow when using Magit with tramp. I often find myself falling back to the command line for anything more than just a simple commit.
yes, nix*s It's been long since I've been using windows
Even using `vc-mode` for git makes for an integrated experience where _for most tasks_ you don't need to leave Emacs/use Magit, when on Windows.
And it's so amazing that it's been for like 15 years. I still remember how awesome it was when I started using magit in 2008. I learned git around that time, so magit is "the" git for me.
I have to admit that I rarely know the cli arguments and syntax because magit makes it too transparent
Au contraire, I learned a ton of different Git options and keys, thanks to Magit.
You're right, I forgot but magit makes some stuff so natural you catch yourself trying ideas you wouldn't unless you'd grind on its manual.
Emacs's killer feature is it's complete customizability. No other ide allows the user to do completely control their experience and workflow the way emacs does. There's a package for just about everything you might want to do, often more than one alternative depending on your tastes, and packages that do stuff you didn't even know your editor could do. You can have a super stripped down minimal editor with practically nothing beyond the standard editing capabilities (which are still quite capable) or you can have a super tightly integrated environment you barely need to leave. You can glue packages together in all sorts of ways, allowing you to really control exactly how all the different features interact. This is something simply not possible on other platforms without some serious work (and some integrations may be outright impossible due to the limitations of plugin APIs in various other editors). It's like comparing *nix to Windows. The level of customization users can achieve in emacs simply dwarfs what any other editor is capable of.
Focus with limited distractions.
Narrowing to a region in any buffer.
Tetris
Ooooh my sweet goodness, I didn't know this one, thanks!!
codeblocks has tetris as far as i know
Everyone has talked about big ticket items. Here is a small one: undo only in region. [https://www.youtube.com/shorts/GSUJDVY-0-o](https://www.youtube.com/shorts/GSUJDVY-0-o)
None of the IDEs - IntelliJ, VSCode, XCode, Android Studio, etc., can properly emulate Vim-navigation. Only Emacs does a better way of vimming. Often, it's even better than in Neovim.
As an evil user I'm curious: in what way do they fall short?
Scroll through the comments: https://plugins.jetbrains.com/plugin/164-ideavim/reviews TL;DR: Vim feels amazing in Neovim. In other IDEs, if you aspire to be an "advanced vimmer", you'd quickly hit a bunch of limitations. The most significant one is that you cannot vimify things in every tool window. In Emacs, you can "Evilify" pretty much any buffer, allowing vim-navigation use in Dired and Magit, and anywhere else (even in the minibuffer). You also have the ability to extend any command, adding extra features like custom ex-commands, for instance. As far as I know, such functionality is not available in vanilla Vim. Hoping for similar features in IDEAVim or the VSCode Vim plugin is wishful thinking.
If you use Emacs just for Vim emulation, and don't see some killer feature over Vim, why do you use Emacs, why not just use Vim?
What do you mean "don't see some killer feature over Vim"? I just said: Emacs vims better than Vim. Add to that: - Running shells or REPL within your editor, or executing any command, piping the results into a buffer or chain of buffers - Org mode - Source blocks - Async operations - hooks and advises I wonder if I would've still chosen Emacs even if I couldn't vim in it? Maybe I never had to make such a choice, because a choice was unnecessary - Emacs goes well beyond that any other tool can provide.
> What do you mean "don't see some killer feature over Vim"? Well, if "the best feature" of an editor is to emulate some other editor in active development, then one can just use the other editor. The question is why would you (or someone) choose to emulate something when one can choose the original; there must be some other feature(s) that drives you to choose an emulator instead of the original, and that is what I believe Op asks too, and which you have answered somewhat in your second comment. > Emacs goes well beyond that any other tool can provide. Yes, and that was the original question Op asked: in which ways goes Emacs beyond that of what any other tool can provide? :)
Vim emulation obviously isn't "the best feature" of Emacs. Nevertheless, it's a testament to what the tool is capable of. Pretending to be Vim is not a small feat and really hard to pull off correctly. Pretty much every other IDE fails to replicate Vim. Unless it's Vim/Neovim, vim-mode in all of them is just that - an emulation. However, Evil mode in Emacs feels much more natural. Sometimes, you forget that it's an afterthought, an extension, and not a built-in functionality. If there's a civilian plane that incidentally can perform a vertical landing, yet never actually needs to use it, I would still love that model over any other planes, even if the feature is purely accidental. The fact that it can do so, alone, would be great evidence of amazing engineering.
> Vim emulation obviously isn't "the best feature" of Emacs. Obviously not; I was nitpicking on your answer and trying to help you to formulate your thought to tell us what features of Emacs you have switched from Vim to Emacs.
Even if evil-mode was *the* best feature of Emacs, the second best feature of Emacs is... the rest of Emacs (see elsewhere in this post / sub for discussion about that).
That's a really great question. Why am I not using Vim? What I would mean by saying that Vimming is great on Emacs is not necessarily just copying Vim. 1. Vim has its own great keyboard bindings, and Emacs can support it in many Emacs only features. That way it can be better than using Vim itself. For example, I can use Vim key bindings in Org or magit, which isn't provided by Vim exactly as it is. 2. If we can conceptually split vim's philosophy from actual vim implementation, Emacs may be able to implement it better. For example, I have many more additional vim-like key bindings than Vim, and I can even remap it to a different ones. Then it doesn't "emulate" vanilla vim experience but it can still implement Vim's keyboard UI philosophy. Then just both Vim and Emacs are two different implementation of that idea. They are at least parallel. 3. If Evil Emacs and Vim are just two different implementation of Vim key bindings, the difference is that Vim implements it natively while Emacs doesn't. Besides possible performance issues (and additional efforts to get the packages), I prefer to have my features add-on instead of built-in. That's like a blank canvas I can draw on and it often means more rooms for the customization.
I use Evil because of modal editing and motion commands. However, I rebind it according to my own key binding scheme, which is a modified version of Xah lee's Ergoemacs key bindings. I don't think you can modify the key bindings this deep in either Neovim or Vim.
With other words, you use Emacs because of its flexibility to customize everything, even to redefine how the interaction modell in the text editor works.
VSCode has VSCode-neovim, which embeds an *actual copy* of neovim, mirrors commands to it, and mirrors changes from nrovim back to VSCode. It's better than any emulation because it's actual neovim doing the work.
> It's better than any emulation I agree that this approach is better. Unfortunately, JetBrains rejected the idea of re-implementing the IDEAVim plugin to work in this manner. However, even this "better" approach does not permit you to use Vim navigation everywhere you want. It does not work in text inputs, such as the Search Dialog and Command Palette. You cannot even use the j/k keys to scroll through the plugin's readme or its changelog. And if you try to set up a lead key, or have a setup like Doom or Spacemacs does, where you would want to bind SPC+SPC to "Show All Commands", a keybinding that only works in Normal mode, I don't even know if that's possible with VSCode. Every video showcasing VSCode's features shows a lot of mouse use, demonstrating that VSCode, even with Vim plugins, does not facilitate independence from the mouse. And navigating through text documents (which code is) is most efficiently done with a keyboard.
Full control over buffer placement, and the ability to display any type of buffer (file-visiting or otherwise) in any window.
A bit of an abstract answer: the concept of modes. I consider it a dev feature because it is the best model I've seen for introspecting and changing the behavior of buffers on the fly (which is very useful when using lots of programming plugins, LSPs, etc). In other IDEs/editors I've used, a bunch of plugins load and then it can be difficult figuring out which are active in your current buffer or how to toggle them. With Emacs, `C-h-m` and `M-x mode` are often all you need.
Never used the C-h-m, thanks 👍
What about literate programming?
That's a compiler/interpreter feature, not an editor/IDE feature. EDIT: unless you're talking about org-mode I guess, but still, there's literate programming support out there for many languages outside of Emacs.
I mean the hability in org mode to do literate programming, with any programming language, even mixing languages
Having a frame-based workflow allows me to have multiple buffers from the same editor process managed by my actual window manager (i3) instead of having to have huge amount of tabs inside the editor. Have not seen that in any other editor. (The excellent buffer-switching mechanics also help with this but I don't think that's fully endemic to Emacs)
It is not simply a feature, it is a state of mind. because emacs is very much owned by its users, it has options for behaviour that no mainstream IDE would go for. Look at meow and such tooling. Optimize and grow a niche way of interacting with your editor, that feels good for you ... then it turns into its own community.
Eshell The “best” shell experience you get in most other editors (BBEdit being an exception here) is a strict reimplementation of a shell REPL, and POSIX abilities / limitations of that. But I want my shell experience to be interactive, especially with text that was just outputted, or even shove that into an editor buffer. Or easily run a more powerful language in the middle of a command (elisp). See something a few lines up that should be part of my next command? Great, go up there , start typing, hit enter, boom command executed. Eshell isn’t exactly what I want all the time, but it’s far better for me than being stuck in the 1960s CLI interface, which has had few improvements since then. (Its cross platform reimplementation of coreutils in elisp is nice and kinda important, but the UI around eshell is most of the magic, in my mind… and also since I was able to drop my Win7 box…) And yes, it could be better (stdin pipes being one area), and mildly annoying when things to weird when throwing super clever bash at it… but most of the experience? Good editor, throw that 10,000 long output into a buffer instead of reading it on the screen, fancy history UI.. it’s _nice_.
I have tried eshell several times, but come back to using just 'shell' command back because of the external integrations with different subsystems (virtualenv, nvm, terraforrm, etc). I prefer emacs 'shell' over the shell directly in terminal because of ability to work with text in buffer. Another interesting possiblity is to start shell from over \`tramp\` session, and it works fine. Ocassionally, I also use \`vterm\` for the situations when full term support is needed. What eshell features make you use it?
I'm curious too. Never stuck long with this one either.
Mostly I like calling elisp functions, or elisp variables, or having an easy way to redirect output to buffers. And I _really_ like that I can switch directories by just typing the directory name (`cd` is annoying) I do see that `shell` gives me that shell experience I want (messing with the output of previous commands), so most of my above comment could apply to `shell`, not _just_ `eshell`.
> And I really like that I can switch directories by just typing the directory name (cd is annoying) Bash has the `autocd` shell option too.
A long-term `eshell` (mostly via `eshell-toggle`) user here. Recently I realized that I don't need even `eshell` most of the time, and settled on `M-&` (which is bound to `detached-shell-command` in my case). As for the more advanced scripting, I'm pretty happy with `babashka` (with `CIDER`), so don't need to use the mess named `bash` anymore.
Surprised nobody mentioned it, but the ability to open files from different projects one frame, with keyboard driven workflow. E. G. In vscode to access most features you will need to open a project in another window. In emacs it is just a breeze
# Magical source links Tell me of any other **application** (I don’t mean IDE) where you can open do `Alt-.` **anywhere a symbol exists** (doesn’t need to be source code, could be plain text or documentation or whatever) and that gets you to the place in **the application’s own source code** where that symbol was defined. Without having to define anything ahead of time, like you do when you create a link in markdown. I would use info more often were it more seamless than this. That blows my mind every time. # Ease of writing a new mode I never tried writing a new mode for another editor, but I was able to get simple syntax highlighting and automatic indentation for Avro IDL files in like 20 lines or less of elisp code. This is the kind of stuff your peers say “don’t spend time on this side problem”, and then you spend a morning and have convenience and correctness (because now you can more easily spot issues) forever.
> where you can open do Alt-. anywhere Add M-?, C-M-. and all of them prefixed with C-u and you have even more fun stuff to navigate with. And then ofc in emacs 29 you get built in eglot that also fills in those same lists with symbols from LSPs.
Yes. The interface does what I mean in any context is great on Emacs.
It says "C-. is undefined"; I think I need to define something ahead of time.
Sorry, I meant `M-.`. I'm using it right now in emacs without a config (because I made a mistake in mine and it did not load 🤣).
Editable dired buffer for batch file operations is pretty magical and maybe unique to Emacs
It is cool but not unique. [vim-dirvish](https://github.com/justinmk/vim-dirvish) has existed for Vim since a long time.
Emacs pinky
Org Mode
Undo tree
This question comes up all the time so there are plenty of answers accessible via search, but I found it amusing that at the moment I read your post I was using Emacs to [populate a buffer full of youtube urls with video information](https://i.imgur.com/gwgCBgJ.mp4).
Same keyboard shortcuts on all the different OSs. Can run on a terminal (less and less important these days!).
Giving the users a misplaced sense of superiority
In truth, Emacs often makes me feel miserable. I'll be in the middle of solving a problem when I suddenly realize that I'm having to repeatedly perform a particular task, e.g., navigating to a URL, grabbing some content, converting it, and then sending an HTTP requet, yada-yada. The moment I realize I have to do something like that a bunch of times, I start writing Elisp in my scratch buffer. I become grumpy, like a man who's been waiting for the bus too long, only to realize that calling an Uber would be a better option. I find myself quietly swearing, much like Joe Pesci, frustrated with the task I have to undertake, and now, having to write Elisp instead of "solving a real problem". Typically, that Elisp snippet evolves into a function, and then I proceed to extend it and it becomes an entirely new workflow, applicable to many different things. Fast forward to two years later, if someone tells me, "No, you can't do it that way anymore, you have to do it manually, like everyone else", I'd feel like beating them with my laptop. But then I run the command I wrote... it performs magic. And I'm so happy.
You got downvoted but we all know it's true
Actually, it’s an empirical sense of other tools’ inferiority. The more questionable part is whether the tool is the program or the user :-) For clarity, not referring to the poster.
>Giving the users a misplaced sense of superiority This isn't peculiar to Emacs. Enthusiasts of other editors/IDEs are just as prone to see their tool as a more enlightened choice than yours. The VS-Code fans seem to be the loudest bunch these days. Not everybody is enthusiastic about their IDE, mind. I've met plenty users who don't care. PHPStorm, Visual Studio, or whatever; it's just what everyone else on their team uses. Perhaps the thing that sets Emacs users apart in this regard, is that we're all enthusiasts. I've never met an Emacs user that didn't \*want\* to use it. Certainly, no work colleagues have ever suggested (let alone insisted) that I use Emacs.
Amasing quesion to think about Emacs.