916 Days of Emacs
sqrtminusone.xyz
sqrtminusone.xyz
Many people don't realize that emacs' default keybindings can be changed to be modal in exactly the same as vim, by using evil.
See this post[1] where I talk about some of the things I've done with emacs -- none of which have anything to do with bindings.
You can do millions of other things too, as I'm not using emacs nearly to its full capacity. Same with vim.
Bindings in editors are like symbols in math. Yes, they're necessary, and you can do a lot with them, but symbols are not nearly all there is to math.
Regarding why edit files in Emacs instead of vim: I simply work on Emacs. I don't use a CLI or a file manager to navigate to my files, I already have projects set up in Emacs and can quickly open files in any such projects. Emacs also holds my note taking system. And when I'm dealing with git, nothing comes close to magit. Also, I've been using the Spacemacs framework for years, which makes it really easy to create such a customized and efficient configuration without much hassle.
Actually in this case I was - but my goal was to use "vanilla" emacs just like I use "vanilla" vi(m). After all, if I'm using vi key bindings... why not just use vi?
Emacs makes extending the editor a breeze. As a new user this just means that you have packages (like VS 'extensions' or IntelliJ 'plugins') for, well, everything. For a more advanced user it means you can automate away many things that are a pain in the ass to repeatedly do in your daily work.
I'd suggest you try Doom Emacs when you have a couple of free hours to get a taste of what a properly configured Emacs can do. And, once you are on it, just press "SPC f p", select 'init.el' and check what popular packages you can activate just by uncommenting a line and doing a 'doom sync'. Then press "SPC f p" and select 'config.el' to check how even "configuration" in Emacs is just elisp code. You are just running a piece of code you can edit and even debug from itself _while_ you are running it (although that'd require a bit more explanation of how it's done) . This should give you a taste of what Emacs is about.
Put this in ~/.inputrc
set editing-mode vi
set keymap vi-commandNote that this feature is broken when you have a PS1 with a \n in it, in an older version of readline/bash (I am not sure which), so if you're having this problem, just upgrade your bash version.
Vim is much more in line with the Unix philosophy. It’s a great editor that can be extended with fzf, ripgrep, lsps, git etc. Emacs has three versions of every plugin and they’re all usually not as good as the thin vim wrapper around fzf etc. If you’re not editing and need email, mutt is a great email client. Irssi is a great chat client. Emacs is very much an all or nothing computing environment.
I am glad I tried Emacs though, because I did love which-key and ended up adding it to my Vim config. And Emacs is slightly easier to quit?
ADVICE: Try both Emacs and Vim vanilla before you do anything else. Downloading a "distro" is really doing yourself a disservice by not showing you just how much either can do without the chrome. And for the love of RMS DON'T USE VSCODE.
(I also don't see how tramp is an issue -- it opens up workflows I wouldn't even have access to without it!)
> (I also don't see how tramp is an issue -- it opens up workflows I wouldn't even have access to without it!)
Because it will randomly freeze and it's single threaded, it's slow, and it's also not novel. Vim can also edit files over SSH, VSCode can run itself remotely.
Can you immediately jump to the source code associated with any key binding, read it, debug it, modify and reload it, etc., regardless of whether it comes from the base distribution or a plug-in?
For me that’s the killer feature of emacs.
I'm pretty sure I did the wrong thing and started with a setup like Spacemacs where random stuff would break and wouldn't even know where to look. Thought I can't seem to loose the muscle memory of vim bindings so evil is a must. On my next round will try dooms or centaur so I learn more under the hood. I do miss magit and helm.
Over SSH? Did you turn on ssh connection sharing in ssh config?
> ControlMaster auto
> ControlPersist yes
> ControlPath /tmp/ssh-%u-%r@%h:%p
massive speedup when you do this, otherwise it starts a new connection for every operation.
Emacs on the other hand is fantastic to work on a computer for a long period of time. I do use evil mode, as I do think it's a much better way to work in a file. Project management, magit, org-mode, being able to edit functionality of the editor within couple of mins to adjust for an temporary change/or indefinitely is what keeps me coming back to emacs.
I've tried vim variations that build in project management and all I'm missing from emacs, but left it at some own written telescope functions to cover base needs.
Love for both, but to me they are not comparable.
(Maybe because I picked up emacs at the same time a good friend picked up vim, and it's been a parallel editor journey for 6+ years)
My problem is that the syntax highlighting, specifically for TypeScript is pretty bad. I have a regular expression (for parsing front matter) that seems to cause Vim’s syntax highlighting to go haywire (it stops and sometimes crashes).
Is anyone aware of a way to get more reliable syntax highlighting in Vim, ideally with a minimum of fuss?
most of the neovim setup scripts (lazyvim etc) get this set up automatically
(Mind you, I have no experience with TypeScript, just saying this as a general remark on what those components do.)
Most blog posts I found seemed to assume you already had a gigantic custom config, plug-in manager, etc. I couldn’t find a “how to set up better highlighting and/or an LSP for people who know Vim but don’t know anything about configuration” guide.
Vim at the end of the day is a terminal application and when it comes to debugging objectively it does not live up to the graphical interface of a proper IDE. Emacs is only slightly better in that regard, it's a GUI application but the age shows as well.
I don't think it's an accident that a lot of vim users are obsessive print-debuggers and that's just a plain handicap coming from living in a terminal. From just observing a lot of developers work I would say not knowing how to fully utilize debuggers and the modern interfaces we have for them is the number one productivity killer.
1. Org mode 2. Magit 3. Wdired 4. Synergy between various components (shameless plug: https://mbork.pl/2023-01-30_The_benefits_of_everything_being...)
2. Magit - Tim Pope is the pope of Vim plugins and fugitive is easily as good or better than Magit. I have never had any issue doing any sort of complex task in git or fixing conflicting using fugitive.
3. Wdired - Tim Pope again has vim-vinegar to improve netrw. Never had a problem or thought about manipulating directories inside of Vim.
4. Again, if you believe in the Unix philosophy then you have to admit that Emacs is simply bloated and trying to do too much and therefore is not really the best at anything. And more importantly, if there's something that Emacs can't do you've screwed yourself because you haven't built an environment around many distinct tools on the command line and it's going to be awkward to integrate.
On the contrary, Emacs tries to do just one thing: provide an Elisp runtime for other applications. It does this fairly well.
Do not confuse Elisp applications like evil, org, calc, magit, etc. with Emacs itself!
The whole "do one thing" slogan is kind of vacuous anyway; e.g., what if my "one thing" is "implement all WWW standards to be able to use any web page"? Is that still "one thing"? If not, then wouldn't implementing only "one" part of WWW be useless?
I actually use emacs solely for org-mode. I find editing single files and even larger projects to be more of a pain that it is worth, so I just use my custom vim to do that.
What keeps me with org mode and emacs is mostly bibliography management. I have emacs set up to read my Zotero directory, and with a keybinding I can insert a reference to a book or magazine or the such. Now, what is really great about this is that when I export the org file (usually to latex->pdf, but also occasionaly to HTML), it exports the references in the style that they need to be in (MLA, APA, Turabian, etc.) and creates a bibliography page at the end of the export with everything that I referenced.
I can also add notes to any references using org-roam, so that I have have annotated bibliographies quite easily.
If I could have something else that does just this, I would drop emacs in a heartbeat. But until I do find that, emacs and org-mode it is.
How do you read email, RSS news, and usenet with vim?
Does vim have a chat client as powerful as ERC?
Mainly, though, is vim programmed in and extended through a lisp, and does it have an entire lisp ecosystem built around it?
Don't get me wrong, I love vim, and used it and vi for 25 years before switching to emacs. But my emacs can do far, far more than vim ever did... and there's no way I'll be switching back until it has all the above and more.
For example, when I go to edit an email I don't have to start up an external editor, so there is no context switching. Also, as emacs is super powerful, the editor that I use to edit my emails is super powerful, unlike the editors in most other mail clients.
Copying and pasting or importing/exporting between the various packages and other emacs buffers that I use is also seamless unlike anything that you do between conventional, separate applications. Everywhere that I go within emacs and everything that I do has the full power of emacs to do it with. I have macros, snippets, and elisp (to name just a few) at my fingertips.
Another advantage is that all these packages that I use (email, my git interface, RSS reader, etc) are all written in elisp and are integrated using elisp, so if you know elisp (which I do) it's easy to modify them to your liking, and have them do exactly what you want. This makes the whole experience super customizable to an extent unmatched pretty much anywhere else.
Without such integration and customizability, virtually all other software that I've used seems primitive and rigid by comparison.
So, yeah, it makes a big difference.
Imagine you put tons of information in vimwiki from your browser.
It's not a far stretch to wish you had a text browser inside of vim to more easily get important information into vim wiki.
At some point the browser could even begin to feel like a hindrance to curating and improving upon your higher quality vimwiki notes.
Emacs is like this, but not just for notes... for pretty much everything.
> just use a window manager like screen or tmux to multi-task.
I'm quite used to my auto-completion and snippets in emacs. As well as my clipboard history. The flexibility of isearch and how intuitive it's UX is.
If I leave emacs I never have all of those familiar things that fit like a glove. I'm in a different world with different rules that is far less malleable, understandable, and introspectable as emacs.
Hopefully that helps make sense of things a bit =)
Generally people prefer to do those sorts of things with specialized applications that are more tailored towards those individual use cases.
If.
-- Source unknown (to me)
It's extremely useful though, I find myself using the fact I can treat my directory list as a text file quite often.
https://generativereview.substack.com/p/tasks-open-source-em...
There are no shortage of Emacs lovers and users who will accept that vim is a better editor. You didn't need to try Emacs to gain that appreciation.
The other tell (common on HN, which has a clear selection bias), is comparing Emacs to an IDE like VS Code. Many, if not the majority, of Emacs users are not primarily using Emacs for coding.
> Vim is much more in line with the Unix philosophy.
Neither follows the Unix philosophy well. And as many people have pointed out, most of the Unix utilities are poor at following it well.[1] The amusing thing about the Unix philosophy is that when you stay within Emacs, the Emacs environment is a much better exemplar of the Unix philosophy than Unix and its tools are. It is a lot easier to compose functionalities in different Emacs packages than it is in UNIX.
I was using a Mastodon client for Emacs and wanted to render LaTeX formulae into rendered equations. I'm an average elisp coder and I got this working in under an hour by composing different Emacs packages.
There are various ChatGPT clients out there. I wanted to integrate it with my Emacs email client (notmuch). It's not a lot of work. I doubt one could integrate things into mutt as quickly/easily.
When reading an email in Mutt, how easy is it to quickly do a Web/network query on a selected text, perform analysis on the result, and display the outcome within Mutt? The analogue is fairly easy in Emacs, despite the mail tool(s) there not having any functionality to do this.
As for Mutt in general: I used it for about a decade. While it has a soft spot in my heart, there is a reason I switched to an Emacs client - before I knew anything about customizing Emacs with elisp. There were lots of gaps in Mutt that other clients out there filled. I miss nothing from Mutt, other than the color scheme.
In many of these cases, there are simply no quick, viable solutions outside of Emacs. People spend a lot of time doing these things in Emacs because it enables them to do more than they could otherwise. Imagine someone who doesn't know any programming complaining about someone else who does. To them they just see a person "wasting" all their time on another "tool".
[1] An example: https://www.johndcook.com/blog/2012/05/25/unix-doesnt-follow...
I've had the same visceral reaction when dealing with grep and find. Overly complex and bloated (albeit extremely useful).
This is a bold claim. Not that fzf isn't good, but I'd like to hear about some specific ways in which fzf is better.
These frameworks offer good defaults that lean towards having lots of features packed in, but it's easy to take away everything you don't want. Both Spacemacs and Doom Emacs can be stripped to almost nothing, leaving you with just a standard for organizing your custom configuration.
To this day, I still swap ctrl/capslock - that is so useful that it should just be a standard.
That said, I'm curious what the weight of emacs was on you? If it was that you were wanting to be in the other editor, than it makes sense that you should stay in the other editor. But this is no different than a lot of things. Is why some folks don't like changing the vehicle type that they use daily. Very little rational argument one way or the other. Such that, yes, you should use what makes you happy. Not only does it make you happy, but you are probably more effective because of that.
What I've noticed about emacs lovers is that they all customize it heavily - I didn't want to do that, since to me the point of using a plain text editor is that it's always available in exactly the same form wherever I happen to be. I did start to looking into all the ways to customize it, but at that point, I couldn't really see much benefit over just using an IDE.
But that's just me.
Even more amusing, I'm fairly certain I had more customization in vim before I decided I wanted to learn lisp. What ultimately killed my customization in all things, was I felt like I was customizing on top of a very shaky foundation. Emacs/vim are stable enough, of course. But building/packaging software is basically a giant playground.
I don't really use Emacs for the editor! It's more because it's a very configurable language runtime/vm with an editor interface.
And org-mode is great too.
Being able to work with `emacs -q` is also important to me for extending Emacs. It's easy to partially roll back a change if I break something in my config, and I can test out new elisp code against base Emacs.
So you not customize vim either?
If you don't, you're missing out 99.999% of the greatness of both editors and doing yourself a huge disservice.
It's like being a carpenter and limiting yourself to only ever using a screwdriver.
No, and I have a specific reason - I ssh into remote boxes a lot, and I want the editor to work more or less the same wherever and whenever I use it. I guess I could customize vi to be a multi-purpose IDE but... that's what I have IntelliJ for.
But the more you use it, the more you're missing out by just using vanilla vi or vim... and I hesitate to mention them in the same sentence because even vanilla vim is thousands of times more powerful than vi.
Vim's true power, however, lies in its customization and plugins. You're really missing out by restricting yourself this way.
Simply put, IDE in the IDEA sense is not the only end goal. Such that that straw man is obnoxious.
Now, it is perfectly fine to just not want to. Such that I am not saying you should reconsider. Just don't be too proud of that reasoning.
"But what if you end up somewhere where you can't do this?" - well, when it happens, I guess I will figure something out! But I've had no problems so far, and I've been doing this a while.
tmbp ~/.emacs.d % git log | tail -n 1
Date: Sat Feb 23 23:30:41 2008 +0000
My config currently works with Windows, macOS and Linux, terminal or GUI, and with any Emacs from 26 to 29, and it behaves about the same in all cases. This didn't take much effort! - though each untested combination have a bad habit of requiring 5-10 minutes of fiddling about.
> to this day I still don't see what the hype was about.
Most of vim is written in C with some interfaces exposed for scripting. Emacs is mostly written in elisp with some C code where necessary. The latter lends itself better to 'hackability' imo
For my own machines, I build emacs and import my saved init.el
On other machines, there is usually a standard vi/vim install that I can use if I am ssh'd in somewhere where I don't have my personalized copy of emacs. If I remember, I'll try to put these five lines[1] in the .vimrc for some saner defaults
If you are editing a remote file there's usually no need to SSH and then invoke an editor.
But in case I am plopped in front of an unknown terminal/have to do something on someone else's machine ... at least I can rely on using the default vim to do basic editing.
If I'm writing a lot of code or doing a refactor needing more thought, I'll do it locally, to be sure.
vim.keymap.set("n", "K", vim.lsp.buf.hover, { buffer = buffnr, desc = "vim.lsp.buf.hover" })
vim.api.nvim_buf_set_keymap(bufnr, "n", "K", "<cmd>lua vim.lsp.buf.hover()<CR>")
better than
nmap K :lua vim.lsp.buf.hover()<CR>
It's like the javafication of vim configuration.
0: https://github.com/RMPR/dotfiles/blob/master/.config/nvim/in...
Tried using vim, neovim, Emacs, mg, etc a month ago and quickly went back to pycharm which hogs resources on my ancient computer.
Have been looking for a "how-to" on various editors. This video seems to be it for neovim.
Offtopic: I'll pay you in blood for configs for fvwm
You might as well try to switch from Notepad to Linux. It's just a type error, and you'll have a bad time.
Reminds me of an old joke: "Emacs would be a great OS, if only it came with a decent text editor..."
what does it take for this tired and false meme to die?
(And that's without the inevitable implementation of some basic OS functions in elisp by various wizards)
There's https://github.com/whily/yalo apparently
(global-set-key (kbd "M-<tab>") #'completion-at-point-using-chatgpt)Emacs is an interactive lisp environment with at text-oriented interface. Text editing is simply another lisp program that manipulates the interface to work well for this specific task.
Emacs also has a built in email client, RSS reader, IRC client, calculator, file browser, web browser, markup language, regex DSL, Vim emulator, terminal emulator, custom elisp based shell, interactive REPL that works for several programming languages, and probably at least 200 more things that I don't even realize exist yet.
I think this makes it much more than just a text editor for sure. I don't know what you want to call it but operating system doesn't seem too far off the mark even if it's a little hyperbolic.
Chrome and Firefox also have all this stuff, but I don't see people trying to conflate a web browser with an OS. See the difference between ChromeOS[0] and Chrome[1].
Then most of these things are not in "emacs" since most of them are packages and not builtin. That was my point. Emacs is insanely customizable through packages, and can essentially run anything. Chrome and Firefox and any other web browser are also insanely customizable through "packages" which you just so happen to download as soon as you enter the URL to the "package" you want, which we really refer to as a web app. But, that doesn't make the browser an OS, and it doesn't make emacs an OS either.
I think this is because they're used in GNU readline. They're also defaults in all the macOS GUIs, though, so maybe not.
Interesting... I always assumed that emacs was around for a while before anybody generalized a "readline" library, but I guess it makes sense that readline would have come first.
and also macOS!
I tried them both and liked vi. Emacs seemed slower. In my undergraduate wisdom, I deemed emacs to be "stupid" and went on with my life using vi.
After I had been programming professionally for about ten years, I decided that my harsh judgement as an undergraduate was often incorrect. (I had also deemed Voltaire, Spanish, sociology, microeconomics and many other things as "stupid", and came to understand as an adult that they weren't.) So, I decided to give emacs another chance.
My conclusion was this: vi is better for touch typists. Your fingers are almost always on the home row. Emacs wants you to hit the meta/alt key a lot, which is difficult for a touch typist. It's much harder than hitting shift. Vi makes you hit escape, but that only happens when you switch modes and it's not that hard to hit.
I noticed that lots of skilled and professional engineers never learned to touch type. That discovery itself was odd to me: why would a professional programmer not want to invest the time to learn to type properly: typing fast boosts your productivity significantly. But they do. And my conclusion was that emacs was for them, because hitting the control/alt key isn't as much of a penalty when you're a hunt-and-peck typist.
I had been playing rogue and nethack for a bit when I started programming. The keys hjkl for doing movement was a natural transition to a vt-100 terminal for writing code in vi.
I had also been coding in LPMuds for a bit and the ed command set was firmly engrained in my mind. With vi being both "move using rogue keys" and "do the fancy stuff with the ed commands" there wasn't even a second thought spent on considering emacs.
- the : key to the right of the 0 on the number row, no Shift needed.
- the Enter key to the right of the P.
I've made both changes to my keyboard layout and, not surprisingly, it's quite convenient.
Downside is, you'll have to move the original keys somewhere else. But since I already intended to totally reshuffle all the non-alpha keys for RSI reasons, it wasn't an issue for me.
The one thing I wanted the most was to avoid any long presses. Everything that requires holding a modifier, even if I do it touch-typing style, with the opposite hand, is unpleasant (to me). So, besides moving most of the punctuation characters to lowercase positions, I also switched to sticky modifiers. (keyd might have some flaws wrt sticky modifiers, and they... get stuck. Not when I want them to be. I might try to go back to XKB.)
Regarding the home-row modifiers, I've only tried moving Control there. I always ended up triggering it by mistake when typing, because when you are typing fast, there is an almost unavoidable overlap in certain sequences, you press the next key before fully releasing the previous key. Some people advice practicing, other software provides various options with timeouts, it's a rabbit hole of work-arounds. So I settled with sticky modifiers.
In emacs you can type exactly the same as in vi/vim if you use something like evil, doom, or spacemacs.
I have not found typing speed to correlate well with productivity. I spend quite a lot of time thinking while coding.
I once worked (mostly remotely) with a guy who I'm pretty sure couldn't touch type. He wrote pretty dense code and used very abbreviated class/variable/method names. But the real clue came from communicating with him via slack. It often felt like talking to someone much less intelligent than I knew him to be. His messages were so terse that I was constantly having to make a lot of guesses about what he was trying to say. Needless to say, it was not a great working relationship.
Of course it doesn’t help at all if you have a long build or deploy process before you can see the outcome of your changes.
hmm.... I wonder if this is the reason Mac OS uses the option key for things like 'kill word' (ctrl+backspace on other OSes or ctrl+w in vi). I have a hard time typing quickly using option/command instead of ctrl.
I also prefer vi-like keybindings.
That’s what we do when we’re younger. Judge things on the wrong basis. Or come up with weird theories on how people who prefer different things do so because they’re deficient in some way—
> Emacs wants you to hit the meta/alt key a lot, which is difficult for a touch typist.
wait what…
> And my conclusion was that emacs was for them, because hitting the control/alt key isn't as much of a penalty when you're a hunt-and-peck typist.
You see that the there are Alt and Control keys on both sides of the (American[1]) keyboard. Right? Touch typing is no harder with Control and Alt than it is with Shift.
> And my conclusion was that emacs was for them, because hitting the control/alt key isn't as much of a penalty when you're a hunt-and-peck typist.
One Year of Experience Ten Times Over: The Comment.
[1] The keyboard (ish) that these silly programs were kind of made for. The “European” keyboard has AltGr on the right side.
This is a false dilemma. Plenty of us type quickly without hunting and pecking, or looking at the keyboard, without home-row touch typing. This comment was typed as such.
There isn't anything "proper" about home row style touch typing, it is merely one of multiple ways to type fast.
With that being said, I consider how I type a combination. I sort of touch type, but Im not completely glued to it. I don't worry if my hands cross as times. However, at the end of the day, if people enjoy touch typing and feel it helps them, they should! No one should swear it off just because I don't feel its that much of a performance boast for me personally.
I've been a touch typist as long as I can remember and have been an avid emacs user for the last 15 years. I used vim for about 2 years before switching. I do have my caps lock bound to CTRL and have ALT+(jkl;) as movement keys in emacs so that might be a sign that there is some truth to what you say.
I would guess the reason that I used vim instead of emacs at the start was the learning curve - I simply couldn't bother to learn all the emacs combinations and program in elisp whereas in vim, I could be somewhat productive without much to learn.
Once I learned emacs, it was hard to go back to anything else but I still use vim on other machines when emacs isn't available.
I used vi and vim for 25 years before switching to emacs, and I spent a ton of time making it very vim like.
Now my emacs can do way more than vim ever did. Things like:
- browse the web through emacs - read my email through emacs - use org-mode to take notes in outline format, with hyperlinks, tables, executable source blocks, etc - use magit, which is a great interface to git
All of these things and more are tightly integrated, so moving text/data between them and editing that data is seamless.
It's all programmed and configured in elisp, and is part of a gigantic elisp ecosystem. Though I much prefer Scheme to elisp, I like elisp far more than vimscript, python, lua, or pretty much any other non-lisp language.
Emacs has some shortcomings (like handling long lines and large files, and certain types of regex handling that vim can do better), and while I do occasionally still fire up vim, I've felt no yearning to go back to it permanently.
For me emacs does everything vim did and far, far more.
Hi, emacs user here, can you elaborate please.
I've asked for them to be implemented in evil, but have been told it's not possible because evil just uses emacs' regex engine, which can't do this.
a+\(b\) → \1
aaaab
aa
b
aa <-- unchanged cos no trailing b
Good luck vimming!
In vim that's a simple abc\zsdef
It also highlights just the "def", which is nice.
To highlight just the "de", you could use abc\zsde\zef
Yes, you could probably use some lisp magic to do the same in emacs, but it's not nearly as easy or convenient.
I've also tried eww, but don't like it as much.
As an Emacs user[1], I agree. The flexibility is really cool, and there are a handful of Emacs applications (notice I didn't call them "packages") that are "killer apps", like Magit, Org-Mode, Calc, etc.
But, even though I do use and like Emacs, I can't honestly recommend it to anyone and I wouldn't even consider it to be a very good programming environment unless you're specifically working in a Lisp/Scheme (where it's awesome).
These days, I mostly use Emacs for programming in Rust and for using Magit as a git porcelain even when not using Emacs for the actual code editing.
Here are the things that suck[2] about Emacs (mostly from the point of view of a programming text editor):
* The UI is slow. Don't tell me that it's "only" when we have long lines, or too much syntax highlighting or whatever. Sure, if I turn off all of the useful programming features, the UI updates fast enough for me to not notice any latency, but any time I open a file that uses a LSP server or equivalent (not just Rust- I've done Clojure, JavaScript, PHP, and C++ in Emacs), the latency for even just moving the cursor around is noticeable and it's distracting.
* Tramp sucks. I don't understand how everyone says that Tramp is awesome and magical. Every single time I've tried to use it to do anything, it's been a bad experience. It's been a few years since I've even tried it, but I remember having to wrestle with ssh-agent authentication, some packages not playing nicely with it (besides the "obvious" ones like LSP-mode), and the whole application hanging if the Tramp session hung for some reason.
* It's actually really HARD to customize properly. The experts say that Emacs is "self-documenting" and "introspectable", but many times, I'll try to customize some behavior or a keymap or something, and I'll read the documentation for a variable or function and it'll say something like "takes a plist of FOO definitions,"--well, what the heck does a "FOO" definition look like? What are the keys for the plist? What are acceptable values for those keys? It's very common to just have to dig through the actual elisp code to find out. Then, you'll find out that your customization doesn't even work correctly because some other mode or function stomps on your code, or gets initialized in a different logic path that isn't affected by your change. Since every feature and every package is different, you have little chance of just figuring out a few conventions or any standard structure for packages.
* Handling buffers is tedious. Sometimes buffers appear and take over the whole frame, sometimes they split the frame and steal focus, and sometimes they split the frame and don't steal focus. And it's very ad-hoc and tedious to try to separate out "background, system buffers" from "my actual work buffers". There are tons of Emacs packages that attempt to make it easier to manage buffers, switch between them more easily, group them in lists, etc.
Like I said, I like Emacs. But, I also run Linux on my personal machines and run a de-Googled AOSP ROM on my rooted Android phone. UX, polish, and convenience are obviously not a high priority for me.
[1]: I've used Emacs to varying degrees and with varying levels of dedication and hardcore-ness since 2008-ish. At a few points, I would've said that I was pretty competent/proficient in Elisp, and have authored some fairly elaborate functions to help me with common tasks within Emacs. I even use to try to do a version of "literate programming" with org-mode and org-mode babel blocks in place of something like Jupyter notebooks for Python.
[2]: Yes, this is a very negative comment, but I tend to complain loudest about the things that I love and care about. I don't complain or criticize things that I don't like or don't want to use.
I feel the pain. I often daydream about spending time customizing it to my needs, and add that to the other 576 ways I want to customize it and don't have time.
And then I sigh and remind myself "At least it's better than tabs!" before I return to my tasks at hand.
Emacs can be slow. I don't use LSP, so can't comment on that, but it's definitely slow on long lines with syntax highlighting.
I don't use TRAMP for exactly one of the reasons you mentioned: it can hang Emacs. I want to avoid that at all costs, because I pretty much live in Emacs.
Emacs' default handling of windows (in emacs terminology it's "windows", not "buffers" that you're talking about) is painful, but you can improve that through various packages, like popper[1]
Depending on what problems you run in to and your skill level, it could be tricky to debug elisp programs. However, compare that to when you run in to some bug in VSCode... how are you going to debug that? You'll probably have to submit a bug report and wait for the developers to get to it (if they ever do)... how is that better than emacs?
Also, remember that you don't have to go it alone in troubleshooting the issues you run in to with emacs. There's a whole community ready and willing to help.
Despite the downsides of emacs, I still use and love it. Every editor has downsides, and emacs is no exception. Its positives far, far outweigh the negatives for me. There's just so much more that it can do than other editors, and it's far more customizable. I very much doubt I'll ever seriously consider switching to another.
Whether I'm complaining about buffer handling or window handling is a matter of perspective. If some event causes Emacs to create a new buffer and to split my frame with a new window to display it, I see that as Emacs handling the buffer *by* creating a window. Not that it matters, because we all know what I mean, because we all share the pain.
It's such a universal issue that there are tons of packages and tips for trying to improve the situation, such as popper. I've tried several over the years and have given up on using any of them because it's always a game of whack-a-mole. There's always some new surprise that is not caught by the helper package and/or your own configuration. So, today, I just have some easy-to-hit key bindings to quickly close the most recent buffer/window, or change focus, etc. It's still a pain in the ass to sift through my buffer lists, but oh well.
> Depending on what problems you run in to and your skill level, it could be tricky to debug elisp programs. However, compare that to when you run in to some bug in VSCode... how are you going to debug that? You'll probably have to submit a bug report and wait for the developers to get to it (if they ever do)... how is that better than emacs?
I don't know anything about VSCode, honestly, but I'll pessimistically assume that its plugins are "closed" to the end-user. Is that true?
But, it's all a double-edged sword. Everyone acts like Emacs is so open that you or I can just go in and fix whatever we want, but that's obviously not true- neither in a strict technical sense (can't edit the tons of inner C code directly in my configs), nor in a practical sense. If Emacs is such that you or I can just hack some ELisp to improve whatever we want, then why haven't you or I fixed our troubles with TRAMP, or slow UI rendering, or the buffers/windows problems?
Is Emacs very hackable? Yes. Much more so than any other editing environment. Is it completely changeable? No. Not even close.
Yet, the trade-off is that there's no structure to anything. Packages all do their own thing, and tap into various parts of Emacs when they're loaded. So, if you load the same two packages in different orders, you can end up with different results. This is especially frustrating with keymaps. Plus, a lot of (most?) packages have auto-loading, which means you don't always even *know* the order in which your packages will load, so sometimes your Emacs will behave differently than other times even with no config changes!
I love the philosophy of making everything hackable, but there's definitely something to be said for enforcing some structure or limits on when and how things are modified.
By far the best part about other programming editors compared to Emacs is that I can install umpteen addons/plugins/whatever and still go to ONE settings menu and see/edit all of my keybindings. And those keybindings will always be correct, no matter how many times I restart the editor, no matter what order I do work during an editing session, etc.
> Despite the downsides of emacs, I still use and love it.
Same here. I love it, but I also hate it. It's so powerful and there's so much potential, but it's also just so bad in a lot of ways.
Closing thought:
Sometimes people say Emacs has bad defaults. But that makes it sound like it's just a matter of some settings. Like you just need to pick a nicer font, pick a nice color scheme, change some key bindings, and turn off the splash screen and that'll do it.
But, if you look at all of the buffer/window helper packages (e.g., popper), and all of the package-management helpers that basically every single one of us use (use-package, straight, elpaca, etc), and how many people ask for help with key binding (and use things like general.el), then it starts to seem like the issue of "bad defaults" isn't really about minor settings tweaks--it's just that Emacs doesn't really *work* that well by default.
I'm going to keep using it, but I'm not going to pretend that it's actually a good editor. It's not even actually a good application platform because a hung SSH connection through TRAMP or a slow-to-load email refresh in gnus or mu4e can take the whole thing down--imagine if your OS went down when an SSH connection dropped...
i would say just a couple of years of vim isn't enough to really become one with the software. think it took me around 5 years to really understand why vim is amazing. took me at least one year just to get the hang of it properly and be highly productive. i can't even type in a normal editor anymore as my brain is wired to vim commands. and i still to this day learn new commands which make my life easier.
that being said i totally understand why people love emacs. but i get a decent amount of the window management stuff just using the tmux.
and vi is installed almost everywhere as an editor which makes editing in 90% of environments a breeze. even when in windows gvim does pretty good.
This is like saying that you have been a mountain biker all your life, but then decided to play the trumpet for one year. Nonsensical conjunction.
They might be a difference of degree along a few axes, but they aren't a difference of kind like trumpets and mountain bikes are.
I mean sure it can sorta half ass a lot of different things but besides org-mode and magit, it's a pretty mediocre and clunky piece of software (clunky, incredibly slow, ugly, etc)
i used to use spacemacs but just wanted a quicker startup while still being reasonably configured... doom emacs is both.
I use both non-evil emacs and neovim, given the mood I am feeling that day. For quick and dirty things, I prefer neovim, and for more extended workflows, I prefer emacs.
But besides functional differences, the two "mediums" feel different. Neovim is clean (and hangs less in general). No bloat. Emacs is a monster, suited towards my liking (with many years of .emacs config).
But as much as I love Lisp, sometimes you want to get away from the bloat and sit quietly with a blinking cursor in vim.
AFAIK/IIRC these bindings are something to do with readline being widely used for CLI interfaces?
Additionally, they work all over OSX too (on text inputs), not just the shell--<C-a>, <C-e> for start and end of line, etc, probably lots of others too that I'm unaware of.
I say that because I have "live documents" that run Jira queries for me, and cross reference defects to other systems behind REST interfaces and can drive the whole thing with a few keystrokes.
(And it didn't take long to put together)
Emacs and emacs lisp, is a bit like Smalltalk in some ways too, once you get the hang of it. (and I've thought of porting that entire workflow I just mentioned to Pharo too)
I wonder how many people know emacs predates gnu-emacs? I remember being skeptical of open source until I saw what gnu emacs could do. Then I got slightly more skeptical when I looked at the code ;-)
is about pre-GNU Emacs, with history of Emacs going back to the mid-1970s.
Or, as the kids these days like to put it, "skill issue tbh".
Skill issue? I have no doubt I could understand glibc if I was willing to pour enough time into that task. That's just the thing: I'm not willing. I have better things to do. Mercifully, I don't have to. Because musl exists.
Anyway, I didn't do much customizing and never got used to vi when I was forced to use it. I don't think I liked the modefulness of vi. Yeah, emacs isn't very unix-y, but the unix-y text editor is ed. You kids get offa my lawn.
I dunno. I can see why folks use VSCode.
When people find out I use Emacs I always caution them against using it. It's taken me a long, long time to be productive in Emacs. VSCode, JetBrains tools, etc. don't have the same requirement and start up time to productivity.
Buying into Emacs does give you a lot though! Emacs way of splitting panels, going through buffers, going through files, always feel better than other applications for me.
Yes!
Some of the people who built GNU Emacs were legit UX geniuses.
Pretty huge learning curve to adopt it.
Two months ago I switched to VSCode. The "Awesome Emacs Keymap" extension by Yuichiro Tachibana made it possible:
https://marketplace.visualstudio.com/items?itemName=tuttieee...
It's not 100% perfect, but close enough. I'm quite enjoying using VSCode now. It's fantastic having a wealth of actually user-friendly features/extensions to choose from.
VSCode is so annoyingly cluttered/blinking/animating/popup-infested by default though. There are a lot of things to disable in the default config.
Then there are a few crucial key bindings missing (like creating and closing split windows) - that seems doable without changing the core VSCode behavior.
A reminder that back in the late 1970s, secretaries at MIT who knew nothing about programming were using Lisp to customize Multics Emacs to their liking and workflow -- and Emacs was far less convenient then than it is now!
The weird trick they used was, telling the secretaries they were just customizing their editor, not programming it!
One really nice feature of MacOS text widgets is the inclusion of basic Emacs key bindings such as C-k, C-d, C-a, etc. Brought forward from the Next days.
I used Zmacs on Lisp Machines back at MIT in the early 80's. A couple of my favorite Emacs-related acronyms are the editor EINE (Eine Is Not Emacs) and its successor ZWEI (Zwei Was EINE Initially).
I remember at one point in the late 80's using Emacs in the shell on SGI Irix workstations. No mouse support at that time for it.
Today I still use Emacs/Slime for my Common Lisp 3D graphics hacking.
When I went to work at IBM I was disappointed that concerns over the Gnu license forced me to use vi for a few years, but I discovered it to be great an editor for me.
I eventually was drawn back to Emacs and now, many years later, I enjoy playing with my config file every week. There is always something new to be added.
It’s org mode and magit that make it impossible to leave Emacs. (Right now I’m experimenting with a configuration where I’ve installed the top 600 most popular add on packages at once. I’m kind of using the wisdom of crowds approach to picking packages this time. Next week it will be something else.)
I've been using ChatGPT (GPT-4) to help me write config (~1,000 lines of elisp code so far) and it's been very interesting/fun. I'm not going back.
I'll start working on a project, and if I run into something that feels wrong about the Doom Emacs default config/keybindings, I'll just open up a conversation with ChatGPT (the GPT-4 model, it's much better than 3.5).
I'll tell it that I'm using Doom Emacs, and then explain what I want, or what problem I'm having, and it will output code that I can try. It's not always correct on the first try, and sometimes I have to have a dialogue with it for a little while before it gets it right. Sometimes it struggles and begins to guess - and for those cases, I'll fall back to doing manual searches in Google, and if that fails, give up entirely and just write myself a TODO comment and keep marching forward.
It's help me set up config quickly that would've taken me a very long time to figure out.
Here's the log:
ChatGPT> Replace the cut shell command with a pure elisp implementation in this code:
(let* ((group-command "cut -d: -f1 /etc/group") ; command to list the groups
(group-data (with-temp-buffer
(shell-command group-command (current-buffer))
(sort (split-string (buffer-substring-no-properties (point-min) (point-max)) "\n") #'string<))))
(message "Selected group: %s" (completing-read "Choose a group: " group-data nil t)))
<shell-maker-end-of-prompt>
(let* ((group-command "cut -d: -f1 /etc/group") ; command to list the groups
(group-data (sort (split-string (with-output-to-string
(call-process-shell-command group-command nil standard-output))
"\n")
#'string<)))
(message "Selected group: %s" (completing-read "Choose a group: " group-data nil t)))
ChatGPT> replace group-command with and call-process-shell-command with elisp that does the same
<shell-maker-end-of-prompt>
(setq group-command "cut -d: -f1 /etc/group")
(setq group-data (sort (split-string (shell-command-to-string group-command) "\n") #'string<))
(message "Selected group: %s" (completing-read "Choose a group: " group-data nil t)))
ChatGPT> What is the elisp equivalent of: cut -d: -f1 /etc/group
<shell-maker-end-of-prompt>
The equivalent Elisp code for `cut -d: -f1 /etc/group` is:
(concat
(nth 0 (split-string (with-temp-buffer
(insert-file-contents "/etc/group")
(buffer-string))
"\n"))
":")
ChatGPT> Give me elisp I can evaluate to check that the elisp you gave is equal to the cut call
<shell-maker-end-of-prompt>
You can evaluate the following Elisp code to check that the Elisp I provided is equal to the `cut` call:
(equal
(concat
(nth 0 (split-string (with-temp-buffer
(insert-file-contents "/etc/group")
(buffer-string))
"\n"))
":")
(shell-command-to-string "cut -d: -f1 /etc/group"))
ChatGPT> It's not equal. the cut shell command gave a list of results. The elisp you gave only gives one result
<shell-maker-end-of-prompt>
I apologize for the confusion. You're right, the Elisp code I provided only returns the first entry in `/etc/group`.
Here's the updated code to get all group names from `/etc/group` file separated by a newline:
(with-temp-buffer
(insert-file-contents "/etc/group")
(let ((groups (split-string (buffer-substring-no-properties (point-min) (point-max)) "\n")))
(mapconcat #'(lambda (group)
(car (split-string group ":")))
groups
"\n")))
When you evaluate this Elisp code, it will return all the group names separated by a newline character, as the `cut -d: -f1 /etc/group` command would.
ChatGPT> Give me elisp to check the equality of it
<shell-maker-end-of-prompt>
You can use the following Elisp code to check the equality of the two commands:
(equal
(with-temp-buffer
(insert-file-contents "/etc/group")
(let ((groups (split-string (buffer-substring-no-properties (point-min) (point-max)) "\n")))
(mapconcat #'(lambda (group)
(car (split-string group ":")))
groups
"\n")))
(shell-command-to-string "cut -d: -f1 /etc/group"))It disobeyed a bit, but here's it giving a simple example:
ChatGPT> Show me the simplest possible example of using completing read. Code only, no explanation
<shell-maker-end-of-prompt>
Sure, here's an example of using `completing-read` without any explanation:
```emacs-lisp
(let ((options '("apple" "banana" "cherry" "date")))
(completing-read "Choose an option: " options nil t))
```
This code defines a list of options called `options`. The `completing-read` function is then used to prompt the user to choose an option from the list. The first argument to `completing-read` is the prompt, the second argument is the list of options, and the other arguments are set to `nil` and `t` to indicate that the user can choose any option and that an exact match is not required.
ChatGPT> Instead of options let's use the list of groups on my linux system as the list for completing read
<shell-maker-end-of-prompt>
Sure, here's an example of using `completing-read` to retrieve one of the groups on your Linux system:
```emacs-lisp
(let* ((group-command "cut -d: -f1 /etc/group") ; command to list the groups
(group-list (split-string (shell-command-to-string group-command) "\n"))) ; split the output into a list
(completing-read "Choose a group: " group-list nil t))
```
This code uses the `shell-command-to-string` function to execute a shell command (`cut -d: -f1 /etc/group`) that lists all the group names on your system. The output of the command is then split into a list of strings using `split-string` function. Finally, the `completing-read` function is used to prompt the user to choose one of the groups from the list. The first argument is the prompt string, the second argument is the list of groups, and the other arguments are set to `nil` and `t` to indicate that the user can choose any group and that an exact match is not required.
ChatGPT> when a group is chosen print its name in the message area
<shell-maker-end-of-prompt>
Sure, here's an example of how to print the selected group name in the message area after the user makes a selection:
```emacs-lisp
(let* ((group-command "/usr/bin/cut -d: -f1 /etc/group") ; command to list the groups
(group-data (with-temp-buffer
(shell-command group-command (current-buffer))
(sort (split-string (buffer-substring-no-properties (point-min) (point-max)) "\n") #'string<))))
(message "Selected group: %s" (completing-read "Choose a group: " group-data nil t)))
```
This code is almost the same as the previous example, but instead of just returning the selected group name from `completing-read`, it is passed as an argument to the `message` function. This will cause the selected group name to be displayed in the message area in the format "Selected group: {group name}".
ChatGPT> use cut instead of /usr/bin/cut, no explanation, code only
<shell-maker-end-of-prompt>
Sure, here it is:
```emacs-lisp
(let* ((group-command "cut -d: -f1 /etc/group") ; command to list the groups
(group-data (with-temp-buffer
(shell-command group-command (current-buffer))
(sort (split-string (buffer-substring-no-properties (point-min) (point-max)) "\n") #'string<))))
(message "Selected group: %s" (completing-read "Choose a group: " group-data nil t)))
```
This code is almost the same as the previous example, but the `cut` command is used without specifying the full path to the executable.
ChatGPT> instead of printing the name to the message area search duckduckgo for that group
<shell-maker-end-of-prompt>
Sure, here's an example of how to search DuckDuckGo for the selected group name using Emacs' built-in `browse-url` function:
```emacs-lisp
(defun my-search-group (group-name)
(browse-url (format "https://duckduckgo.com/?q=%s" group-name)))
(let* ((group-command "cut -d: -f1 /etc/group") ; command to list the groups
(group-data (with-temp-buffer
(shell-command group-command (current-buffer))
(sort (split-string (buffer-substring-no-properties (point-min) (point-max)) "\n") #'string<))))
(my-search-group (completing-read "Choose a group: " group-data nil t)))
```
This code defines a new function `my-search-group` that takes a single argument (`group-name`) and sends a search query to DuckDuckGo using the `browse-url` function. The search query is generated using the `format` function, and includes the selected group name.
The rest of the code is similar to the previous example, but `my-search-group` is called with the selected group name instead of displaying it in the message area. This will cause Emacs to open the default web browser and search DuckDuckGo for the selected group name.
- Ellis Kenyő, on being called an "elisp mage"
Haha, this is exactly what I fear if I tried to switch from Neovim to Emacs. I have a pretty bare-bones Emacs config that I started a while back, but haven't spent the time to really get it going.
Very cool, makes me wonder why I didn't think of this before, I've been using Emacs since forever.
However that was only due to being in UNIX environments where IDE was a foreign word, and nothing compared to the likes of Borland offerings.
Nowadays there are plenty of IDE choices for UNIX like workloads, I don't miss Emacs, and basic VI knowledge is enough for editing configuration files on bare bones POSIX systems.
How practical is EMACS for a non-programmer? My preferred environment is FreeBSD + i3WM. I'm a sysadmin, I have no programming skills so anything beyond tweaking the odd configuration file is of no interest to me.
I know that being able to write elisp is a major component of using emacs, but how usable is it without being able to write your own programs?
This video by a self professed non-programmer about using Emacs in the broader Unix ecosystem might pique your interest enough to give it a try:
I don't even want to spend 45 mins a month fiddling with config. I really don't understand Emacs people.
Emacs is essentially an IDE for developing emacs.
(while (not (eobp))
(while (not (markdown-table-at-point-p))
(forward-char 1))
(markdown-table-align)
(goto-char (markdown-table-end)))
It's 0.43 hours a day, which is 26 minutes, not 45. (Hint: 0.5 hours is 30 minutes.)
When we need to quickly debug or carry out a complex operation at work? People gather around my machine. Once you're set up with things like org-mode, magit, lsp your productivity goes up a lot.
Some people like to customize their environment to their exact specifications. Others will use whatever is available and never change it.
That is not required. Although default Emacs is pretty barebones (from a modern interface standpoint, not features) one can get a pretty good kickstart by using something like Spacemacs or Doom emacs and only sprinkling a bit of configuration here and there.
I too had a pile of config accrued over years - mostly porting features from other editors to Emacs. After adding Doom, I have just a few lines, it does all the rest.
The point is - usually on other editors you need to either wait for someone to create a "plugin" to do what you need, or you need to create a full blown plugin yourself, which is not a small task. In Emacs, it's extremely easy to create functions that will do tasks for you. And that gets addictive.
That is what I thought when was motivating myself to continue diving into vim and emacs. In the end it turned out that the this this problem of "difficult extensibility" exists only in my head but not in VSCode or IntelliJ IDEA. Eventually, you can do magic on your files with sed/python/any other language in terminal and this most likely is better solution because it is editor-agnostic and good for automation.
That being said, I'm also one of those people that break my Emacs config often, and I have a different version on each PC I use.
Not every user is like this though! Many try to keep their setup as stable as possible.
The problem is in the terminology: Config
Replace the word with programming and it will all make sense. People who write Javascript code to build custom tools for their own use are doing the exact same thing as Emacs users tweaking their config.
These days when I have time I'm writing elisp to make it easier for me to write math notes. One org roam node per concept/definition/proof. However, I'm building a graph: If a definition of a math object involves prior knowledge, I want to link to those nodes. The default org roam interface makes this a pain, so I want an interface that prompts me for the title, and lets me select dependencies one by one. It then inserts the node, with links to all those dependencies.
Where does all this code go?
In my config.
The stumbling block I usually come to is wondering how to utilize these data sets on my smartphone in an efficient and effective manner.
For those who worry about runaway configs, I highly suggest starting with sanemacs for a good minimal configuration you can start with and build from a good foundation on.
i have control left of space, alt left of that. capslock is also alt, and is used for most alt presses.
Someone please enlighten me with links, guides or just a comment as to what's in Emacs that makes it productive and special.
There's a lot of non-emacs filler but it's still the best emacs e-zine
(for people who don't know it by this name: this is apparently the Korean name of the board game Go.)
Like an integrated program suite, you can move from program to program (Emacs modes), copying your data around easily, and using similar (or the same) commands and user interface for every program/mode, making data manipulation in many ways simple and fast.
Like a Lisp Machine, Emacs is totally user programmable at every level, making both debugging easy when/if something breaks, and extensible with your own programs, ranging from simple keybindings, or macros, to full major modes. (Most major modes in Emacs started out as a single person’s personal customizations.)
It's just that the levels of GNU Emacs don't get as low-level as the Lisp operating system of Lisp Machine (which is an actual computer with its operating system, and not an programmable editor written on top of operating systems, which were written in C and a bunch of other languages). The levels of a Lisp Machines go all the way down to (for example) the network stack and the actual instructions interfacing with the hardware. GNU Emacs usually re-packages the underlying OS services (I/O, file system, GUI, ...) with a Lisp-based API and one programs with that.
There is a huge machinery with lots of complexity to deal with listing directories, either with ls, a GNU provided ls, or by providing a complex emulation of ls.
I am genuinely asking for an experiential guide/comment rather than a link to documentation.
Work pays for everything, I just dont want to wait 10 minutes for an environment to change.
That is, unless you're talking about launching emacs each time you want to edit a single file, then emacs won't load instantly like vi will.
This is a good article about the problem https://discourse.doomemacs.org/t/why-is-emacs-doom-slow/83/...
I’ve heard plenty of arguments, but they kind of suck to be honest. They’re more like rationalizations for why they stick to what they know.
I just don’t get it. Why use inferior tools?
Both are lighter weight. Big deal, buy a faster computer. It’s nothing compared to your salary.
Both may let you type slightly faster and move around faster. Maybe. But that’s not the bottleneck anyway.
Why? Am I missing something or is it just an irrational attachment to software they learned long ago and prefer to stick with rather than learn something new?
They seem awfully limited to me by comparison.
https://github.com/neoclide/coc.nvim
Or
https://github.com/neovim/nvim-lspconfig
https://github.com/hrsh7th/nvim-cmp
No different than installing plugins in VSCode for completions, they all work via calling out to a LSP server using https://microsoft.github.io/language-server-protocol/
When you don't understand something it's only natural to be unaware of its capabilities, yes.
Can you list your most important feature(s) in chosen your ide or editor that you suspect emacs doesn't have or can't easily have?
`lsp-ui` does it for Rust at the very least but probably for other languages too.
- browse the web
- read/send/edit email, RSS news, usenet
- chat on IRC and other chat networks/protocols
- use org-mode to edit notes in an outline format with hyperlinks, executable code blocks, a spreadsheet, etc
- use magit, one of the most powerful git interfaces
- read and edit PDFs and LaTeX with visual LaTeX symbol substitution right in the editor
- program and configure the editor in elisp, with a whole elisp ecosystem used for every plugin (this alone would make me switch away from any other editor to emacs)
- use thousands of other scripts and plugins that are the result of 50 years of development
- absolutely everything customizable to the nth degree, as emacs is more of an editor construction kit than a mere editor
‘You can install a vi emulator.’ - Waste of time. I already have vim.
My vimrc file still works. New machine? Just install vim and copy my vimrc over.
Emacs is a totally different experience. Emacs is essentially the interface side of an operating system. There is really no replacement for it except a UNIX command-line with a bunch of CLI tools for things like news and email that people have forgotten about.
Combine this with my tiling window manager and I pretty much only have to use my mouse to interact with web browsers. That's the killer feature that makes VS Code and Intellij _feel_ inferior to me.
Now I wouldn't go so far as to say that VSCode and Intellij are _actually_ inferior to Emacs. I think both are great in their own right, but after years of familiarity I have a fluency with Emacs (because of the keyboard oriented interface) that I could never have with them.
To be fair, for someone without emacs fluency I would probably steer them towards VSCode and Intellij as they are definitely more approachable. In fact, I have done exactly that for several of my friends and colleagues.
They keep developing and they are up to date with many/all programming-features. There are bunch of extensions that VScode just doesn't have despite it's huge extension store.
Also the main thing for me about these editors and especially Emacs is that you can program it. Not just configure it but actually program and do anything with it. You can hook into any piece of the code and change it. You can read the source code of any "extension" and patch it on the fly. I don't think I'm aware of any other editors that allow that.
It's huge power.
I'm saying (from my pov, which may be wrong) that they don't seem to have as good of an IDE experience. Certainly the out-of-the-box experience with emacs/vim is much worse. And the learning investment is pretty steep. But even if you configure everything as an expert would, the experience still seems lacking to me.
As for the other things, Emacs has support for many more languages than VSCode or Intellij. An example of this, is support for (g)awk, or non-posix shell scripts, lots of lisps, jq, various config file formats, and other things that aren't "hot" right now.
There are other reasons too, like Emacs being a true FOSS project, which is important to me. There are lots of other things, these are just a few ottomh.
How are you sure VSCode and IntelliJ will be around in 10 years? 20 years? Why invest in learning a new tool every couple of years? How do I know MS doesn't suddenly kill VSC?
Also, why would I want to use an editor which calls home every few minutes? How can I be sure VSCode does not send my password files etc. to MS or OpenAI or whatever?
Also, Emacs extensibility and flexibility is unparalleled. I can mold it to fit _my_ workflow instead of molding myself to fit the workflow of some guys at MicroSoft.
Also, Emacs is self-documenting and has ridiculous introspection capabilities. My favorite example: do VSCode/IntelliJ have a counterpart of `view-lossage` (https://www.gnu.org/software/emacs/manual/html_node/emacs/Mi...)?
Also, the fact that Emacs is so keyboard-oriented (as others have mentioned) is not really about _objective speed_, but _subjective feeling of friction_ (and lack thereof).
Also, working with Emacs is so much fun. It's a piece of software so helpful that it almost feels like an A.I. assistant. ;-)
So, plenty of reasons for me.