From Vim to Emacs in fourteen days (2015)(blog.aaronbieber.com)
blog.aaronbieber.com
From Vim to Emacs in fourteen days (2015)
https://blog.aaronbieber.com/2015/05/24/from-vim-to-emacs-in-fourteen-days.html
181 comments
Emacs vs Vim is like comfort food for software-related online discussions.
I guess, given how evil-mode just gets better and better every day I'm not really seeing many people moving in the other direction, at least based on the blog posts.
No shade on Vim, people like it and are productive in it. I see it like using Sublime Text, lots of people can get away with it, but I need more doodads in my editor.
And hey, nobody is like "Notepad++ vs. Visual Studio", which I think kinda matches the mismatch (or maybe "Notepad++ vs Atom" or something)
No shade on Vim, people like it and are productive in it. I see it like using Sublime Text, lots of people can get away with it, but I need more doodads in my editor.
And hey, nobody is like "Notepad++ vs. Visual Studio", which I think kinda matches the mismatch (or maybe "Notepad++ vs Atom" or something)
Here's the thing, though. I don't use Vim as an IDE. I use it on live servers to change configs / scripts / app code (don't tell anyone) quickly and efficiently. I don't think "extra doodads" would help with that, and I'm not sure I'd want to manage those dependencies on my platform anyway.
If I'm actually developing something that's part of a greater whole, then I'm using a fully fledged IDE like PyCharm (but with the VIM emulator plugged in for when I need it, of course ;-D).
Likewise, no shade at Emacs, though. Several of my favorite colleagues use it!
If I'm actually developing something that's part of a greater whole, then I'm using a fully fledged IDE like PyCharm (but with the VIM emulator plugged in for when I need it, of course ;-D).
Likewise, no shade at Emacs, though. Several of my favorite colleagues use it!
Contrary to what many might expect, Emacs tools are quite good for performing sysadmin tasks:
* TRAMP for remote editing. It's more powerful than Vim's netrw remote editing capabilites and can handle root-owned files on remote servers. It's so extensible there's even a package that allows you to edit files inside Docker containers running on remote servers.
* Dired. It's the best text-based file manager out there IMHO, and it integrates very nicely with TRAMP.
* Org mode. It can be used like Jupyter notebook, but is far more powerful. You can write each code block in any language you choose, pass data between them, and make each of them run on different servers. This is very useful for sysadmin tasks especially in professional environments because it allows you to document each step in a reproducible manner as you're executing it. You can then just share the org document for your cowokers to review.
I personally use Vim for coding and Emacs for non-trivial sysadmin tasks.
* TRAMP for remote editing. It's more powerful than Vim's netrw remote editing capabilites and can handle root-owned files on remote servers. It's so extensible there's even a package that allows you to edit files inside Docker containers running on remote servers.
* Dired. It's the best text-based file manager out there IMHO, and it integrates very nicely with TRAMP.
* Org mode. It can be used like Jupyter notebook, but is far more powerful. You can write each code block in any language you choose, pass data between them, and make each of them run on different servers. This is very useful for sysadmin tasks especially in professional environments because it allows you to document each step in a reproducible manner as you're executing it. You can then just share the org document for your cowokers to review.
I personally use Vim for coding and Emacs for non-trivial sysadmin tasks.
Changes to PRODUCTION app code on server?!
I’ve seen this happen once or twice at my current company. Not the best of times...
Everyone has a test environment. Some are lucky enough to have a separate production environment.
One of our oldest and proudest flame-wars.
In 2001, Slashdot held a poll for Best Flame War. [0] The winner, by quite a margin, was Operating System, but the text editor wars (presently being fought at [1]) weren't listed as an option. Personally I'm also rather fond of the tabs-vs-spaces debate.
[0] https://slashdot.org/poll/699/best-flame-war
[1] https://news.ycombinator.com/item?id=26431864
In 2001, Slashdot held a poll for Best Flame War. [0] The winner, by quite a margin, was Operating System, but the text editor wars (presently being fought at [1]) weren't listed as an option. Personally I'm also rather fond of the tabs-vs-spaces debate.
[0] https://slashdot.org/poll/699/best-flame-war
[1] https://news.ycombinator.com/item?id=26431864
I need to make a conscious effort to stay the hell away whenever this comes up here on hn. It's not the only topic that does this, but it's by far the least productive one, lang wars can at least be educational.
And it's even more useless fluff than it was back in the day because people used Vim and Emacs in large numbers back then. These days the vast bulk of professional developers use Visual Studio Code. Compared to VSCode vs. IntelliJ, Vim vs. Emacs is a sideshow at best.
[deleted]
> Vim vs. Emacs is a sideshow at best.
Until you need to ssh into a server and edit something.
Until you need to ssh into a server and edit something.
It's funny you mention that.
https://www.murilopereira.com/how-to-open-a-file-in-emacs/
The summary is that the author tried to open a remote file and Emacs froze for several seconds. He dived deep into finding out why that was and how to fix it, pointing out how great Emacs's introspection is that one can find solutions to problems like these.
And then two thirds of the way into his essay, he has this:
> More recently, I’ve been very put off by the performance and stability (or lack thereof) of building large scale software via Tramp. This has been sufficient to have me looking out again. On a whim, I installed VSCode for the first time and tried its “remote development” capabilities and holy smokes are they good. Getting up and running was trivial and the performance was great. Saving files was snappy and LSP worked out of the box. What a different experience from my carefully-put-together, half-working, slow Emacs setup.
And then later:
> Improve Tramp performance to match the experience of using terminal Emacs via SSH, or VSCode’s Remote Development.
https://www.murilopereira.com/how-to-open-a-file-in-emacs/
The summary is that the author tried to open a remote file and Emacs froze for several seconds. He dived deep into finding out why that was and how to fix it, pointing out how great Emacs's introspection is that one can find solutions to problems like these.
And then two thirds of the way into his essay, he has this:
> More recently, I’ve been very put off by the performance and stability (or lack thereof) of building large scale software via Tramp. This has been sufficient to have me looking out again. On a whim, I installed VSCode for the first time and tried its “remote development” capabilities and holy smokes are they good. Getting up and running was trivial and the performance was great. Saving files was snappy and LSP worked out of the box. What a different experience from my carefully-put-together, half-working, slow Emacs setup.
And then later:
> Improve Tramp performance to match the experience of using terminal Emacs via SSH, or VSCode’s Remote Development.
Well for what it's worth, here is something about VS Code LSP and embrace-extend-extinguish.
https://news.ycombinator.com/item?id=25719338
https://news.ycombinator.com/item?id=25719338
This isn't about LSP but specifically pylance. Let's not confuse the issue.
(Incidentally, I don't even use lsp on Emacs, although I may give it a try).
(Incidentally, I don't even use lsp on Emacs, although I may give it a try).
I think the thing is that pylance is a python LSP. And it's proprietary. So they embraced python LSP, extends it so that the additions are proprietary. And pylance might become the defacto python LSP. Typical EEE. Python is hugely popular, it's everywhere - so even if one hates it, might end up having to use it.
Also the remote extensions are proprietary [1]. This has been discussed on HN before.
[1] https://github.com/VSCodium/vscodium/issues/240
Also the remote extensions are proprietary [1]. This has been discussed on HN before.
[1] https://github.com/VSCodium/vscodium/issues/240
> So they embraced python LSP
They did not embrace LSP. They invented it. LSP came from MS.
> And pylance might become the defacto python LSP.
Nothing is preventing someone from creating another python LSP that will work with the LSP tools. MS is not unique in this. Jetbrains makes proprietary products that are well embraced by the Python community.
They did not embrace LSP. They invented it. LSP came from MS.
> And pylance might become the defacto python LSP.
Nothing is preventing someone from creating another python LSP that will work with the LSP tools. MS is not unique in this. Jetbrains makes proprietary products that are well embraced by the Python community.
> LSP came from MS.
Thanks, today I learned.
Yeah anyone is free to create, same as anyone is free to create remote extensions for VSCodium. So far nobody seems to have done it. Even if somebody does it, it might not match the quality and features of MS extensions.
MS has a history of EEE. Jetbrains doesn't, and as far as I know they are no bullshit no dark patterns high quality.
Thanks, today I learned.
Yeah anyone is free to create, same as anyone is free to create remote extensions for VSCodium. So far nobody seems to have done it. Even if somebody does it, it might not match the quality and features of MS extensions.
MS has a history of EEE. Jetbrains doesn't, and as far as I know they are no bullshit no dark patterns high quality.
I get where you're coming from. It's just amusing that many people talk about how great it is to use LSP with Emacs, but are simultaneously recommending not to use MS tools :-)
If one is concerned enough not to use VSCode because it is MS, then one should also not use LSP.
If one is concerned enough not to use VSCode because it is MS, then one should also not use LSP.
LSP is great. The thing about VSCode is dark patterns. VSCode is great, one sees that it's MIT licensed, downloads it uses it and is like wow nice. After a while realises that the official build is not FOSS licensed and contains telemetry code. So one finds 'VSCodium' which is a community port without telemetry. You carry on working but now remote things are not working. One looks why - the only reason is MS made it proprietary. Remote is essential for lots of developers. One feels f*cked by MS. Few years ago, Github's 'Atom' editor was getting popular. Then MS bought GH now Atom reduced to atoms - can't see it anywhere - though getting updated.
> They did not embrace LSP. They invented it. LSP came from MS.
I don't think this changes the issue: EEE became CEE (Create, Extend, Extinguish).
I don't think this changes the issue: EEE became CEE (Create, Extend, Extinguish).
VS Code supports editing files over ssh. https://code.visualstudio.com/docs/remote/remote-overview
Yeah but you have to install 100+mb into a .vsserver folder to get it to work
[deleted]
This always comes up. How can we still not edit a remote file via ssh using whatever you want!?!
From
>> Debian's Vim maintainer switches to Emacs - https://news.ycombinator.com/item?id=341492 - Oct 2008 (32 comments)
He warned me I should switch from vi to emacs because prolonged vi usage causes hair loss. :)
>> Debian's Vim maintainer switches to Emacs - https://news.ycombinator.com/item?id=341492 - Oct 2008 (32 comments)
He warned me I should switch from vi to emacs because prolonged vi usage causes hair loss. :)
Maybe, but prolonged emacs use causes carpal tunnel syndrome!
Only if you don't use a keyboard the way it was intended. For example, Ctrl-c should involve both hands. If you press Ctrl-c with only your left hand (there's a reason your keyboard has a right Ctrl), you will gradually hurt your wrists. Emacs can accelerate this, since a lot of things begin with Ctrl-x, assuming that you never use the right side Ctrl.
I have never had carpal tunnel-like symptoms yet, though I just realised I've only used left ctrl for the past 10 years. I'll definitely be more mindful of that. Do you have any more resources on avoiding common typing pitfalls, or specific wrist movements one should avoid while typing? Should capitalising your sentences be a two-hand action as well, considering I normally only use left shift?
Macs don't have a right Ctrl, unfortunately.
In college I used Emacs, because I had a romance with lisps and just really enjoyed extending stuff. Also used Sawfish as my window manager, etc. The modal thing in vi(m) was hard for me to wrap my head around and the bizarre config of vim seemed so inelegant.
But when I got a gig as a sysadmin running a few thousand servers w/ a slew of Unixes (Solaris, BSD, HP-UX, Linux) I finally bit the bullet and learned vi, because it was the only common denominator (oh, man and ksh88 because so many bash-es were so broken on those platforms).
Now I find modal editing very natural and productive and don't miss the keyboard gymnastics of emacs. I find I get pissed at every text editor that isn't vi. Outlook, this text box, etc.
I use IntelliJ (and do Python and Go in it) with vi binding for large long-lived projects and just vim/neovim in a terminal for scripts, short-lived stuff, and quick edits. The bindings in IntelliJ are good enough, although sometimes I forget and try to do things, like run a file through awk.
I play with using VSCode with vi bindings from time to time, but honestly just forget to use it much.
I have a smallish vim config with a handful of plugins, mostly for linting. I'm comfortable with it and haven't ever really found it lacking. And I don't feel the need to maintain a codebase for my config like I enjoyed doing in college. I guess I garden in my garden vs my config files and am not so focused on some kind of concept of purity. Heck, I think I have the default background on my mac.
But when I got a gig as a sysadmin running a few thousand servers w/ a slew of Unixes (Solaris, BSD, HP-UX, Linux) I finally bit the bullet and learned vi, because it was the only common denominator (oh, man and ksh88 because so many bash-es were so broken on those platforms).
Now I find modal editing very natural and productive and don't miss the keyboard gymnastics of emacs. I find I get pissed at every text editor that isn't vi. Outlook, this text box, etc.
I use IntelliJ (and do Python and Go in it) with vi binding for large long-lived projects and just vim/neovim in a terminal for scripts, short-lived stuff, and quick edits. The bindings in IntelliJ are good enough, although sometimes I forget and try to do things, like run a file through awk.
I play with using VSCode with vi bindings from time to time, but honestly just forget to use it much.
I have a smallish vim config with a handful of plugins, mostly for linting. I'm comfortable with it and haven't ever really found it lacking. And I don't feel the need to maintain a codebase for my config like I enjoyed doing in college. I guess I garden in my garden vs my config files and am not so focused on some kind of concept of purity. Heck, I think I have the default background on my mac.
> this text box, etc.
I always keep a GVIM window open so that I can type text there and then paste those into other places that are not vi.
It also helps that vi is a lot more stable than certain websites and is less likely to lose my text. It's nice to be able to just copy&paste without having to re-type the same text when browser crashes.
I always keep a GVIM window open so that I can type text there and then paste those into other places that are not vi.
It also helps that vi is a lot more stable than certain websites and is less likely to lose my text. It's nice to be able to just copy&paste without having to re-type the same text when browser crashes.
As always, the Emacs experience is better: https://github.com/zachcurry/emacs-anywhere
:)
:)
It's literally inspired by vim-anywhere.
I know. I use vim-anywhere because I never bothered to set up Emacs Daemon.
Funny you say that, because I always find myself reverting to emacs and, even after playing with config distros like Spacemacs and Doom Emacs, I've settled on on a severely minimal config with mostly default keybinds, and magit on the side because it is the best interface to git I've ever had the pleasure to use. I also enjoy running linters and test commands in a compilation buffer and hitting 'g' to re-run/refresh it after making changes in the files I'm working on. And the way emacs handles undo/redo feels intuitive to me in a way I can't really explain.
Essentially, I get modality when I want an interface. And the rest of the time, I type.
I still make sure that I know good-enough vim and nano so I can do what I want outside of my own environment.
Essentially, I get modality when I want an interface. And the rest of the time, I type.
I still make sure that I know good-enough vim and nano so I can do what I want outside of my own environment.
I learnt something cool about Emacs undo on a recent HN thread.
If some text is selected before invoking undo, then undo happens only within the selected region.
If some text is selected before invoking undo, then undo happens only within the selected region.
If you're a firefox user, check this out: https://addons.mozilla.org/en-US/firefox/addon/tridactyl-vim...
Perhaps it's just my wimpy laptop, but last time I tried tridactyl it was pretty slow. Vimium (https://addons.mozilla.org/en-GB/firefox/addon/vimium-ff/) has been a bit better for me, although I think it's quite a bit less configurable than tridactyl.
me too, plus some oddities like c-d and c-u are not remapped to d and u like on vimium, while not standard compliant it's a must because it is overridden by a browser bind. otherwise it's fast but there was more stuff which was not great/
[deleted]
This article fails to explain -why- one would want to switch to emacs from vim.
Org-mode and configuring emacs in a lisp-like are cool, but are not worth re-learning everything for me. I put that time in already by reading "Practical Vim" by Drew Neil and other vim literature online. I'm sure everyone is already aware, but vi is available basically everywhere. This has saved my ass at least twice where I couldn't access vim or had internet access to install XYZ editor.
So as a power vim user I see no reason to switch. If I can't use vim, most editors now have support for reasonable vim bindings. So I use that for Jetbrains' products / Joplin / Insomnia / etc.
Org-mode and configuring emacs in a lisp-like are cool, but are not worth re-learning everything for me. I put that time in already by reading "Practical Vim" by Drew Neil and other vim literature online. I'm sure everyone is already aware, but vi is available basically everywhere. This has saved my ass at least twice where I couldn't access vim or had internet access to install XYZ editor.
So as a power vim user I see no reason to switch. If I can't use vim, most editors now have support for reasonable vim bindings. So I use that for Jetbrains' products / Joplin / Insomnia / etc.
How many lines of vimscript have you written? No, copy-pasting config lines from someone's dotfiles doesn't count. How many times have you opened the source code of some vim plugin you are using and tried to modify what it does?
If I were to hazard a guess: zero. That was also me during ten years of vim usage. Vim encourages the mindset of mastery = learning a bunch of tricks, remembering them and incorporating them into muscle memory.
Emacs on the other hand encourages the mindset that my editor is a programmable tool, I am a programmer, I can make it do whatever I want. You are always just one click away from the source code implementing any functionality of your editor, which you can, if you choose to do so, modify and evaluate on the fly.
> vi is available basically everywhere
Emacs-like shortcuts are also available wherever you have readline (e.g. many shells).
>This has saved my ass at least twice where I couldn't access vim or had internet access to install XYZ editor.
In those situations, I also still use vim. But 99% of the time, I am not on some remote machine, I am on my personal computer, so I can choose to use a tool that is not installed by default. The basic vim commands I have internalized over the years are sufficient for those odd jobs.
>So as a power vim user I see no reason to switch.
To each their own. Personally, I think that Emacs is a much more rewarding tool to master.
>most editors now have support for reasonable vim bindings
So does Emacs :)
In fact Emacs' vim plugin is probably has the most feature rich of all the vim emulations.
If I were to hazard a guess: zero. That was also me during ten years of vim usage. Vim encourages the mindset of mastery = learning a bunch of tricks, remembering them and incorporating them into muscle memory.
Emacs on the other hand encourages the mindset that my editor is a programmable tool, I am a programmer, I can make it do whatever I want. You are always just one click away from the source code implementing any functionality of your editor, which you can, if you choose to do so, modify and evaluate on the fly.
> vi is available basically everywhere
Emacs-like shortcuts are also available wherever you have readline (e.g. many shells).
>This has saved my ass at least twice where I couldn't access vim or had internet access to install XYZ editor.
In those situations, I also still use vim. But 99% of the time, I am not on some remote machine, I am on my personal computer, so I can choose to use a tool that is not installed by default. The basic vim commands I have internalized over the years are sufficient for those odd jobs.
>So as a power vim user I see no reason to switch.
To each their own. Personally, I think that Emacs is a much more rewarding tool to master.
>most editors now have support for reasonable vim bindings
So does Emacs :)
In fact Emacs' vim plugin is probably has the most feature rich of all the vim emulations.
The vim landscape today is pretty incredible. Neovim nightly supports native LSP (and Treesitter!) so you get all the functionality that VSCode pioneered.
Neovim also supports configuring your setup in lua, certainly a better language than vimscript (which I agree isn't great) and lets you write native neovim plugins in lua.
Emacs of course supports LSP (and probably treesitter), I'm just reflecting on the fact that (neo)vim continues to evolve.
I think without neovim, vim popularity would have continued to degrade. Though the community, especially with packages like Coc.vim, continues to push vim along and bring support for external features. I personally think neovim is the future over vim given its management and native support for LSP and Treesitter.
In either case, its awesome both editors are still going strong! While VSCode and JetBrains' IDEs are great, they always feel crowded compared to vim. I love that both (neo)vim and emacs still have such large communities behind them. Both are great examples of software that is old, receives improvements and evolves, and continuously delivers value to their users.
Neovim also supports configuring your setup in lua, certainly a better language than vimscript (which I agree isn't great) and lets you write native neovim plugins in lua.
Emacs of course supports LSP (and probably treesitter), I'm just reflecting on the fact that (neo)vim continues to evolve.
I think without neovim, vim popularity would have continued to degrade. Though the community, especially with packages like Coc.vim, continues to push vim along and bring support for external features. I personally think neovim is the future over vim given its management and native support for LSP and Treesitter.
In either case, its awesome both editors are still going strong! While VSCode and JetBrains' IDEs are great, they always feel crowded compared to vim. I love that both (neo)vim and emacs still have such large communities behind them. Both are great examples of software that is old, receives improvements and evolves, and continuously delivers value to their users.
Vim syntax isn't a "bunch of tricks" though. It's a syntax, with enough consistency that you're able to figure out new commands without looking them up. For example, "d$" cuts from your cursor to the end of the line, and since "y" stands for yank/copy, you can then figure out that "y$" copies from your cursor to the end of the line.
And also, the syntax is shared with other Unix tools like man, less, sed, etc.
I'm not saying Vim is objectively better than Emacs or anything, but the basic commands gg, G, d$, dd, y$, yy, ^, $, and so on really are handy as a tool.
(Also worth noting that the syntax has overlap with Regex, so "^" and "$" are very natural choices for commands that jump to the beginning and end of the current line.)
And also, the syntax is shared with other Unix tools like man, less, sed, etc.
I'm not saying Vim is objectively better than Emacs or anything, but the basic commands gg, G, d$, dd, y$, yy, ^, $, and so on really are handy as a tool.
(Also worth noting that the syntax has overlap with Regex, so "^" and "$" are very natural choices for commands that jump to the beginning and end of the current line.)
It's certainly easier than editing an XMonad config without knowing Haskell.
I don't think that there is an XMonad config file. XMonad is a library and the thing in your home directory is a program that gets compiled into being your window manager, implemented with that library.
Emacs and Vim aren't quite like that.
Emacs and Vim aren't quite like that.
I use both vim and xmonad and have to disagree, as I have a lot of experience configuring both. Config for both is using a file in a programming language specific to each. One being compiled is not a significant difference IMO.
> How many lines of vimscript have you written? [...] How many times have you opened the source code of some vim plugin you are using and tried to modify what it does?
Zero, thank god. I have enough work to do at work. I don't need to make a hobby out of my editor.
Zero, thank god. I have enough work to do at work. I don't need to make a hobby out of my editor.
"How many lines of vimscript have you written? No, copy-pasting config lines from someone's dotfiles doesn't count. How many times have you opened the source code of some vim plugin you are using and tried to modify what it does?"
Well, I haven't had a real reason to do so. I used to use more plugins but I slowly am paring it down to a much more minimal configuration. I'm not a huge fan of vimscript, but I don't think it's worth changing over to emacs for. Plain vi actually isn't that bad, depending on the version.
"Emacs-like shortcuts are also available wherever you have readline (e.g. many shells)."
Sure, and I appreciate the irony of learning some emacs shortcuts for readline while using vim. But that's different from editing. The only time I've seen vi not available is in scratch/alpine linux containers where busybox essentials weren't installed either.
I suppose my use case is different because I work a lot with containers, and minimal install systems in general.
Well, I haven't had a real reason to do so. I used to use more plugins but I slowly am paring it down to a much more minimal configuration. I'm not a huge fan of vimscript, but I don't think it's worth changing over to emacs for. Plain vi actually isn't that bad, depending on the version.
"Emacs-like shortcuts are also available wherever you have readline (e.g. many shells)."
Sure, and I appreciate the irony of learning some emacs shortcuts for readline while using vim. But that's different from editing. The only time I've seen vi not available is in scratch/alpine linux containers where busybox essentials weren't installed either.
I suppose my use case is different because I work a lot with containers, and minimal install systems in general.
I somehow find myself commenting on these threads the most on this site purely to bring up vterm. I think the combination of a well-polished Emacs (like DOOM), evil-mode for vi modal editing everywhere and critically vterm/emacs-libvterm make for a great workflow[1].
Sure there's all the regular Emacs value-adds (Org-mode, Magit, TRAMP etc.) and there's no rush to start learning them, but navigating local/remote codebases all the while treating Dired filesystem views, regular files AND terminal ptys as buffers with full modal editing I find to be something of a special power. This has been possible for a long time with eshell/shell etc. but vterm really takes the lag out of it IMO. This workflow was certainly my gateway drug to Emacs. It displaced nearly two decades of vim for editing and tmux for terminals. YMMV.
[1] I wrote a bit about the workflow and continuing to train better with vim bindings using Emacs https://martin.baillie.id/wrote/evil-motion-training-for-ema...
Sure there's all the regular Emacs value-adds (Org-mode, Magit, TRAMP etc.) and there's no rush to start learning them, but navigating local/remote codebases all the while treating Dired filesystem views, regular files AND terminal ptys as buffers with full modal editing I find to be something of a special power. This has been possible for a long time with eshell/shell etc. but vterm really takes the lag out of it IMO. This workflow was certainly my gateway drug to Emacs. It displaced nearly two decades of vim for editing and tmux for terminals. YMMV.
[1] I wrote a bit about the workflow and continuing to train better with vim bindings using Emacs https://martin.baillie.id/wrote/evil-motion-training-for-ema...
> This has been possible for a long time with eshell/shell etc. but vterm really takes the lag out of it IMO. This workflow was certainly my gateway drug to Emacs.
Wait... wait... vterm works with TRAMP? How?
If this lets you navigate remote filesystems as in eshell without the lag on each command that results in... I'm sold.
EDIT: Oh, I found https://github.com/jixiuf/vterm-toggle which seems to open a vterm pane and ssh into the remote host. Which is close enough, I suppose! (Though I would miss being able to just `cp` from a remote path to a local path as if they were both local.)
Wait... wait... vterm works with TRAMP? How?
If this lets you navigate remote filesystems as in eshell without the lag on each command that results in... I'm sold.
EDIT: Oh, I found https://github.com/jixiuf/vterm-toggle which seems to open a vterm pane and ssh into the remote host. Which is close enough, I suppose! (Though I would miss being able to just `cp` from a remote path to a local path as if they were both local.)
FWIW Neovim has shipped with libvterm as a built-in terminal emulator for years now, I think since 2015? It's the main reason I switched from vim to neovim. Vim itself integrated libvterm somewhat later, too.
I just use emacs+evil for org only. Org is feature rich (bloated?) but these dynamic code blocks in documents are just too good.
I prefer vim for everything else and the general "minimalist" approach in particular. Emacs seems to appeal to people who like to do everything within one tool.
I prefer vim for everything else and the general "minimalist" approach in particular. Emacs seems to appeal to people who like to do everything within one tool.
I know org.mode is a deep rabbit hole - but do you have an example of "dynamic code blocks in documents"?
I've recently switched my "notes.txt" buffer in (neo)vim to markdown ("notes.md) - along with a slightly more magical syntax plug-in - and I'm pleasantly surprised by the quality of life improvements from having multiple code/script snippets highlighted in-line (eg: ```SQL (... Snippet...) ``` in a paragraph followed by some notes and a block of bash etc).
But I rarely execute the blocks in / from vim - I do a bit of copy-pasting though (I don't generally fit a terminal buffer/window in vim, I use a separate window with gnome-terminal or Sakura. I tried term-in-vim, but didn't quite like the flow. Maybe I should try again).
I've recently switched my "notes.txt" buffer in (neo)vim to markdown ("notes.md) - along with a slightly more magical syntax plug-in - and I'm pleasantly surprised by the quality of life improvements from having multiple code/script snippets highlighted in-line (eg: ```SQL (... Snippet...) ``` in a paragraph followed by some notes and a block of bash etc).
But I rarely execute the blocks in / from vim - I do a bit of copy-pasting though (I don't generally fit a terminal buffer/window in vim, I use a separate window with gnome-terminal or Sakura. I tried term-in-vim, but didn't quite like the flow. Maybe I should try again).
I made a video[0] showing off the power of org-babel, which is the part of org that lets you embed dynamic code blocks in your document. In the video I write a little essay[1] on how git stores data that has a lot of dynamic content that is managed by org. It's a bit like reproducible research or literate programming, but for me it's all about writing technical documents that are easy to keep consistent when things change.
[0]: https://www.youtube.com/watch?v=0g9BcZvQbXU
[1]: https://gitlab.com/spudlyo/public/-/blob/master/git.md
[0]: https://www.youtube.com/watch?v=0g9BcZvQbXU
[1]: https://gitlab.com/spudlyo/public/-/blob/master/git.md
Thanks for this video, this is the one I link to when asked for a Babel demo.
> This article fails to explain -why- one would want to switch to emacs from vim.
In other words it does one thing, hopefully well. The philosophy behind the original vi, and IIRC originally vim too — didn’t it previously have an explicit non-goal of adding an embedded terminal emulator? If it did, those days seem over, so you IMO you might as well use an editor that does many things well (eg. having a proper designed language as the default for configuration, not the bodge that is vimscript with Lua as just a secondary option ), if you’re going to use an IDE and not an actually minimal text editor like vis or sam.
Fortunately you don’t need to ‘re-learn everything’ with evil-mode. I doubt other editors’ support for reasonable vim bindings is as complete as the common base of Spacemacs and Doom, they certainly aren’t as complete of operating systems, capable of being your WM (EXWM) or your init system or shell (http://www.informatimago.com/linux/emacs-on-user-mode-linux....), nor capable of running in a terminal over ssh.
In other words it does one thing, hopefully well. The philosophy behind the original vi, and IIRC originally vim too — didn’t it previously have an explicit non-goal of adding an embedded terminal emulator? If it did, those days seem over, so you IMO you might as well use an editor that does many things well (eg. having a proper designed language as the default for configuration, not the bodge that is vimscript with Lua as just a secondary option ), if you’re going to use an IDE and not an actually minimal text editor like vis or sam.
Fortunately you don’t need to ‘re-learn everything’ with evil-mode. I doubt other editors’ support for reasonable vim bindings is as complete as the common base of Spacemacs and Doom, they certainly aren’t as complete of operating systems, capable of being your WM (EXWM) or your init system or shell (http://www.informatimago.com/linux/emacs-on-user-mode-linux....), nor capable of running in a terminal over ssh.
One good reason is programmability. You can write lisp scripts to automate some routine editing.
For me the main reason I prefer emacs is the key bindings are better.
Another reason that emacs (the real thing) is available everywhere. You can install it on Linux, Mac and Windows. And you can run it in console mode (terminal) as well as GUI (even on Windows).
For me the main reason I prefer emacs is the key bindings are better.
Another reason that emacs (the real thing) is available everywhere. You can install it on Linux, Mac and Windows. And you can run it in console mode (terminal) as well as GUI (even on Windows).
For me the main reason I prefer emacs is the key bindings are better.
Genuine question, why do you think emacs key bindings are better?
Genuine question, why do you think emacs key bindings are better?
Take for example, incremental search. Emacs has it by default. Vi being older didn't have it, but vim has it. It has to be turned on. Then it doesn't work as well as emacs. In emacs you can type to search then ctrl+s to move to next match then continue to type to edit the search string, and so on. This is just one example. Replace has advantages in emacs when it comes to case matching. And it goes on and on.
> It has to be turned on.
"set incsearch" is all it takes to get incremental search. Are you trying to argue that Emacs defaults are so good that you never need to change it? I find it hard to believe you never have any "setq"s in your Emacs config.
> In emacs you can type to search then ctrl+s to move to next match then continue to type to edit the search string
In vim you can type to search then n to move to next match then /<ctrl-p> to continue to edit the search string. But seriously, a fuzzy searcher or :grep would be more useful for that sort of thing.
> Replace has advantages in emacs when it comes to case matching.
Case matching is a thing with Vim's regex too.
> And it goes on and on.
But all of the things mentioned so far are about basic editing capabilities that any decent editor would support one way another.
"set incsearch" is all it takes to get incremental search. Are you trying to argue that Emacs defaults are so good that you never need to change it? I find it hard to believe you never have any "setq"s in your Emacs config.
> In emacs you can type to search then ctrl+s to move to next match then continue to type to edit the search string
In vim you can type to search then n to move to next match then /<ctrl-p> to continue to edit the search string. But seriously, a fuzzy searcher or :grep would be more useful for that sort of thing.
> Replace has advantages in emacs when it comes to case matching.
Case matching is a thing with Vim's regex too.
> And it goes on and on.
But all of the things mentioned so far are about basic editing capabilities that any decent editor would support one way another.
Incremental search needs to be enabled, yes, but it’s just one line in your .vimrc.
What do you mean by “type to search”? Sounds like you’re omitting the “start search” key combo.
Your example in Vim:
* / to start a forward search
* type in the word and hit enter
* n/N for next/previous match
To modify the search:
* q/ opens your search history with the cursor at the last searched string
* modify the search string using standard Vim keys
* hit enter to search
What do you mean by “type to search”? Sounds like you’re omitting the “start search” key combo.
Your example in Vim:
* / to start a forward search
* type in the word and hit enter
* n/N for next/previous match
To modify the search:
* q/ opens your search history with the cursor at the last searched string
* modify the search string using standard Vim keys
* hit enter to search
> type in the word and hit enter
That's the problem. When you hit enter you have left incremental search. In emacs you can refine the search string without leaving. Ctrl+s and Ctrl+r goes prev/next and you can simultaneously refine the search string (by typing any other char) without leaving incremental search. Given how important search is (for a programmer) this alone is worth the price of entry. But there are many more things.
That's the problem. When you hit enter you have left incremental search. In emacs you can refine the search string without leaving. Ctrl+s and Ctrl+r goes prev/next and you can simultaneously refine the search string (by typing any other char) without leaving incremental search. Given how important search is (for a programmer) this alone is worth the price of entry. But there are many more things.
Thank you for that note on q/ ... I knew about q: for command history, and was wondering if there was an equivalent for search history.
That depends on what the meaning of "everywhere" is.
He actually has a talk about it: https://www.youtube.com/watch?v=JWD1Fpdd4Pc
For me, I wanted access to org-mode, as well as the emacs ecosystem of packages.
emacs has good vim emulation through the evil package.
Doom emacs, is a decent place to start for a vimmer.
emacs has good vim emulation through the evil package.
Doom emacs, is a decent place to start for a vimmer.
[deleted]
you might find vscode to be a great replacement for vim... using the neovim extension you have a pretty much seamless true vim in vscode (with a few rough edges). some other extensions like magit for vscode are gaining functionality and polish coupled with best in class support for language server makes it pretty solid as a replacement.
I went in the other direction about 5 years ago after 20 years of always installing Emacs on every computer I ever used. Vim has had a much bigger impact on my productivity.
Partly because of excellent plugins (VSCode, Visual Studio), partly because, for some reason I bothered to learn Vim shortcuts to degree I never did with Emacs. And I just love that vi and vim is quick and available on my various cloud servers.
Once in a while I toy with the idea of going back and using evil mode (I keep reading about org mode).
Partly because of excellent plugins (VSCode, Visual Studio), partly because, for some reason I bothered to learn Vim shortcuts to degree I never did with Emacs. And I just love that vi and vim is quick and available on my various cloud servers.
Once in a while I toy with the idea of going back and using evil mode (I keep reading about org mode).
> after 20 years of always installing Emacs on every computer I ever used.
You don't need to install emacs on every computer you use. The emacs on your laptop has tramp so you can edit any file on any computer you have ssh access into.
You don't need to install emacs on every computer you use. The emacs on your laptop has tramp so you can edit any file on any computer you have ssh access into.
I've used vim for years, but a few months back started using org mode with Spacemacs evil mode.
I like org mode a lot. It has a lot of functionality that makes it useful for all sorts of things beyond plain text editing. Using evil meant I didn't need retrain for common editing operations, although certain org-mode specific functionality means learning new Emacs-style key sequences.
Other than that, I still haven't learned anything about using plain emacs, so I only use emacs for editing org files. They're a different enough entity from ordinary text files that switching editors to use org mode doesn't bother me.
I like org mode a lot. It has a lot of functionality that makes it useful for all sorts of things beyond plain text editing. Using evil meant I didn't need retrain for common editing operations, although certain org-mode specific functionality means learning new Emacs-style key sequences.
Other than that, I still haven't learned anything about using plain emacs, so I only use emacs for editing org files. They're a different enough entity from ordinary text files that switching editors to use org mode doesn't bother me.
Fwiw Spacemacs is another good combination of the two, similar to evil mode.
https://www.spacemacs.org/
https://www.spacemacs.org/
+1 for Doom. I tried spacemacs for a while but didn't find it enjoyable. Doom was exactly what I needed and now I don't use anything else.
Spacemacs has been gradually breaking over the years, and is a lot more complex than Doom. I migrated about a year ago, and save for some fairly minimal muscle-memory adaptation and modifications to some packages' config, it's been very smooth sailing.
Thank you. Went down a small rabbit hole reading about Doom & Spacemacs and am pretty sure I'll pull the trigger, to get org mode and magit.
Tangentially related: I've used emacs for coding for a decade, and for email for a few years. I love it. But I'm missing out on its arguably strongest feature: elisp! My config file is a tragedy of stuff I hamfistedly cobbled together. I'd like to learn this skill properly, and thus conquer the world (I assume this makes me able to).
Can anyone recommend a resource? I speak some C-like languages, and Python and Haskell, but no LISP at all. I'm an emacs user, but have only superficial knowledge of how emacs actually works.
Can anyone recommend a resource? I speak some C-like languages, and Python and Haskell, but no LISP at all. I'm an emacs user, but have only superficial knowledge of how emacs actually works.
More replies than you can shake a stick at here.
https://emacs.stackexchange.com/questions/47318/how-can-i-st...
(I've been cluelessly hacking at emacs for decades, and there's ALWAYS something new to learn.)
https://emacs.stackexchange.com/questions/47318/how-can-i-st...
(I've been cluelessly hacking at emacs for decades, and there's ALWAYS something new to learn.)
Thanks!
https://www.emacswiki.org/emacs/LearnEmacsLisp looks pretty good, too, actually.
It probably took me longer than 14 days to learn vim after using emacs for years, it was worth it - mainly and specifically I switched because vim’s modal nature means fewer finger contortions to reach 6 modifier keys simultaneously as required with emacs - that was giving me RSI symptoms. I’ve been happy with vim since and it tends to be more easily available in remote systems. To each their own though - both editors are ok :)
> If, like me, you’re curious enough to give Emacs a try...
So curiosity rather than conversion. Six year later is he still using Emacs? Went back to Vim? Moved on to something else?
I have enough years invested in muscle memory of Vim itself and various plugins that what curiosity I have about Emacs is well controlled. I doubt I have runway left to get to the same productivity in another editor.
So curiosity rather than conversion. Six year later is he still using Emacs? Went back to Vim? Moved on to something else?
I have enough years invested in muscle memory of Vim itself and various plugins that what curiosity I have about Emacs is well controlled. I doubt I have runway left to get to the same productivity in another editor.
Well the author used Evil mode which is vi emulation for emacs and quite popular. Their last post that was obviously about emacs was late 2019 but they don’t blog much. So I’d guess they still use emacs
An interesting path is to go from regular emacs to emacs with vim bindings, which is what I did, also in around 14 days. Its painful, but good for you brain. And you get the best of both worlds, or so I like to think.
I tried that too for a bit over two weeks. In the end I had a comfortable configuration, but with noticably worse performance and a lot of inconsistencies. Whenever I use Emacs I kind of like the concept but at the same time feel like the good parts are buried beneath countless random additions that should have been optional plugins. I dare to claim that >95% of Emacs users do not use its integrated Tetris implementation, for example.
You might be right, though I do not have a good reference to compare Emacs + evil with. I think by default Emacs is a somewhat mediocre editor, the one thing that saves it is the unparalleled customizability, which should allow you to slowly prune the randomness and inconsistencies. But it is a commitment, not everybody wants a relationship with their editor. Btw, I regularly play Tetris in emacs ;-)
Definitely. But the thing is, coming from Vim with a custom configuration I'm at a point where I'd first need to reverse engineer parts of Emacs and reconfigure a ton just to get back to where I left Vim. And if I learned something when trying it out then it's the futility of trying to cram Vim into it expecting it to work without a Frankenstein's monster vibe. There's always something off or incomplete. I don't think I'll try it again soon, but if I do it would be with something like God mode; for one because Evil mode somehow breaks Emacs when run in the terminal, and also because Vim and Emacs just don't mesh together well imho. They are both excellent at doing very similar things, but their approaches are just not compatible.
This is a great point. Personally, the only reason I would want to switch to Emacs is Org mode but the muscle memory for custom Vim and Tmux keymaps is hard to give up.
emacs is very customizable.
I had the same fear before switching to emacs(in evil mode), so I changed some of the default shortcuts that I was accustomed in vim(e.g. nerdtree/treemacs). It's not that hard.
The whole enormous productivity boost that you get from Org mode(and org babel/literate programming) is well worth the temporary minor inconveniences of learning the tool.
I had the same fear before switching to emacs(in evil mode), so I changed some of the default shortcuts that I was accustomed in vim(e.g. nerdtree/treemacs). It's not that hard.
The whole enormous productivity boost that you get from Org mode(and org babel/literate programming) is well worth the temporary minor inconveniences of learning the tool.
FWIW, I use emacs(with evil) inside tmux, so you can keep your flow if you are willing to invest in the transition.
magit is the best git porcelain (interface) that I’ve ever seen. I’m a longtime emacs user, but even if I wasn’t, I’d provably use magit as my git interface
> So curiosity rather than conversion. Six year later is he still using Emacs? Went back to Vim? Moved on to something else?
He was as of Jan 2020.
He was as of Jan 2020.
I went from vim to emacs for development in go and python. I Went with doom emacs, which is a configuration distribution already prebuilt which is friendly to vimm users (ie, evil mode). It was rough at first, required writing lots of cheat sheets and also changing workflows a little. I feel much more productive in emacs than vim. IMHO, its more straightforward to google "How to do X in emacs" than "how to do X in vim" and actually end up with a productive configuration change.
For those who use Vim bindings, and would like to try out emacs, I'd suggest trying Spacemacs:
https://www.spacemacs.org/
It has "evil mode" by default — the vim bindings.
I picked this up at Jane Street, where much of the internal tooling is in emacs. I still use it wherever I can't get a good vscode setup, and it has some advantages over vscode.
https://www.spacemacs.org/
It has "evil mode" by default — the vim bindings.
I picked this up at Jane Street, where much of the internal tooling is in emacs. I still use it wherever I can't get a good vscode setup, and it has some advantages over vscode.
I picked up spacemacs earlier this year but have since switched to Doom emacs: https://github.com/hlissner/doom-emacs it's smaller, faster, and you configure it in a way that's closer to vanilla emacs. The size makes it more tractable to learn. The creator & primary maintainer is more active, funny, and helpful than the spacemacs maintainer who I believe is on hiatus.
I wish someone had told Doom about it before I picked up spacemacs so maybe this post will benefit past-future-me.
I wish someone had told Doom about it before I picked up spacemacs so maybe this post will benefit past-future-me.
I've been using Spacemacs for Clojure development for years but stable has been stuck on the same version for ages so is it actually maintained?
You should switch to develop. They are working on release 300 and there are commits being merged daily.
It's been thaty way for years so not very encouraging. With develop I can't just click Update Packages. Any advantages these days of staying with Spacemacs over Doom?
Thanks! It looks good. I'll check it out more.
Am I the only person who uses Lem? An Emacs-clone written and extended in Common Lisp rather than the weird version of Lisp Emacs uses.
https://github.com/lem-project/lem
https://github.com/lem-project/lem
I tried it, but the underlying Roswell system isn't perfect at least.
Simple Make fails on linux out of the box.
And the look&feel and features are very far from emacs.
Simple Make fails on linux out of the box.
And the look&feel and features are very far from emacs.
Vim is my go-to terminal-based text editor, and I used it for a decent amount of time, but when I finally decided to switch to something like Sublime Text, I never felt the need to go back.
Maybe it's because I'm not a "touch typist" who uses a home row and all that stuff, so the keybindings optimized for that don't really help me that much.
I do like Vim though, and it's an insanely useful skill to have because I can SSH into any server and edit config files like if I were straight up programming.
Maybe it's because I'm not a "touch typist" who uses a home row and all that stuff, so the keybindings optimized for that don't really help me that much.
I do like Vim though, and it's an insanely useful skill to have because I can SSH into any server and edit config files like if I were straight up programming.
You can enable Vintage Mode in Sublime Text to get the best of both worlds.
Well I'm long time emacs user who switche to emacs from vi(m) in essentially the time it took to go through the C-h t tutorial.
While today I dont't use Emacs as the day-to-day editor (I use VSCode, for a bunch of not entirely good reasons that mostly have to do with macOS) I think that exposing people new to unix to emacs/zile makes more sense than to vi(m). And then there is the "every mac textfield understands default emacs key bindings" effect...
While today I dont't use Emacs as the day-to-day editor (I use VSCode, for a bunch of not entirely good reasons that mostly have to do with macOS) I think that exposing people new to unix to emacs/zile makes more sense than to vi(m). And then there is the "every mac textfield understands default emacs key bindings" effect...
I've tried to get into emacs, VS Code, and Sublime (all w/Vi keybindings, of course), but I always seem to find myself back in Vim (or Neovim).
I want to love emacs with default bindings but find them unergonomic to the extreme. However I think VIMs bindings and multimodal text editing is a false economy, so I don't want to just use evil-mode (spacemacs or DOOM). In other IDEs and OSs there is a consistent scheme for copy, paste, undo, redo but no consistent scheme for new-line-above/below or movement near the home row keys using modifiers. I've been experimenting with alt+[some homerow keys] for movement and left-hand w/modifiers for changes similar to ergoemacs, in vscode. The realisation I've had is that there is an absence of standardized keybindings for text editing across IDEs/editors and the complexity and lack of interoperability rolling-your-own make that approach universally avoided. This means we are in a rut going back and forth between emacs and vim and OS keybindings, and the editor wars are just a symptom of a greater problem. The real issue is that there is not enough R&D on efficiency and human-oriented design and/or this hasn't influenced current standards to a great enough degree. Aside from in a terminal I'm not convinced (if timed/tested) the average coder using the mouse heavily with left-hand shortcuts would be any less capable than a vim guru. Accuracy with a mouse is something that can be improved too, just look at competitive FPS games. I'd also posit the mouse coder spent more time learning coding and less time fiddling with his tools.
Does anyone know where I could find more info about this stuff?
Does anyone know of any research comparing the efficiency/speed/stress of VIM users to, say, VS Code keybindings or emacs ones?
I am a productive vim user already and have just learned standard emacs bindings and ergoemacs bindings within a few hours. This is not a matter of a vim-naiive person avoiding learning the tool. I do have a preoccupation with tools rather than getting stuff done with them... That's our curse isn't it?
Does anyone know where I could find more info about this stuff?
Does anyone know of any research comparing the efficiency/speed/stress of VIM users to, say, VS Code keybindings or emacs ones?
I am a productive vim user already and have just learned standard emacs bindings and ergoemacs bindings within a few hours. This is not a matter of a vim-naiive person avoiding learning the tool. I do have a preoccupation with tools rather than getting stuff done with them... That's our curse isn't it?
Here we go again. Vim vs. Emacs. A decades-old argument that actually doesn't have any merits.
Because Vim and Emacs are two distinct categories. The only thing that makes them similar is that they are both based on something. That something is an idea. And not just an ordinary, everyday concept, but an influential, holy grail type of thing.
Vi and the concept of the modality is an incredible, powerful, fantastic model. People who never hardheartedly tried to learn Vi-model just don't get to say anything about it. Can you respect an opinion about CRISPR coming from someone who has no clue about polynucleotide chains and DNA?
Yes, Vim is not overly intuitive for a complete beginner. Like many, perhaps most awesome tools, it too has a certain level of sophistication. You cannot enter the Suez or Panama Canal gates' control room and suggest removing all those knobs, switches, buttons, etc., and instead, install one colossal touch screen because that would be "a much more intuitive interface".
Vim is hard to learn, but you see, there's usually a strong correlation between something that's not so easy to acquire and simplicity gained later. Conversely, things that are easy to pick up, very often later become cumbersome and annoyingly counter-productive. Rich Hickey's "Simple Made Easy" rhetoric very nicely manifests that.
So yes, Vi-model is an incredible idea. Vim, Neovim, Evil, etc., are just implementations of that idea.
Now, Emacs is based on another mind-blowing idea. The idea of practical notation for lambda calculus, what is known as Lisp. Lisp, probably can be crowned as the most important idea in computer science. It's just hard to think of something more influential than Lisp. Emacs is just a practical implementation (and frankly, not the best one) of that idea.
Arguing what's better - Emacs or Vim is like debating what was more important in the history of health care - the invention of anesthesia or discovery of penicillin.
Both Vim and Emacs are awesome, and one is not better than another. If you can't see that - then probably there's a big hole in your understanding of at least one of the ideas they are based on.
Because Vim and Emacs are two distinct categories. The only thing that makes them similar is that they are both based on something. That something is an idea. And not just an ordinary, everyday concept, but an influential, holy grail type of thing.
Vi and the concept of the modality is an incredible, powerful, fantastic model. People who never hardheartedly tried to learn Vi-model just don't get to say anything about it. Can you respect an opinion about CRISPR coming from someone who has no clue about polynucleotide chains and DNA?
Yes, Vim is not overly intuitive for a complete beginner. Like many, perhaps most awesome tools, it too has a certain level of sophistication. You cannot enter the Suez or Panama Canal gates' control room and suggest removing all those knobs, switches, buttons, etc., and instead, install one colossal touch screen because that would be "a much more intuitive interface".
Vim is hard to learn, but you see, there's usually a strong correlation between something that's not so easy to acquire and simplicity gained later. Conversely, things that are easy to pick up, very often later become cumbersome and annoyingly counter-productive. Rich Hickey's "Simple Made Easy" rhetoric very nicely manifests that.
So yes, Vi-model is an incredible idea. Vim, Neovim, Evil, etc., are just implementations of that idea.
Now, Emacs is based on another mind-blowing idea. The idea of practical notation for lambda calculus, what is known as Lisp. Lisp, probably can be crowned as the most important idea in computer science. It's just hard to think of something more influential than Lisp. Emacs is just a practical implementation (and frankly, not the best one) of that idea.
Arguing what's better - Emacs or Vim is like debating what was more important in the history of health care - the invention of anesthesia or discovery of penicillin.
Both Vim and Emacs are awesome, and one is not better than another. If you can't see that - then probably there's a big hole in your understanding of at least one of the ideas they are based on.
20 years of vim user here. I learnt Emacs for just one thing. Magit!
Except that I don't have any other use for Emacs.
Except that I don't have any other use for Emacs.
If anyone wants to give a try, it's worth noting a few things if you come from vim:
- if you are on osx, you'll may find the gui rendering quite laggy if you are using a Retina display. Using the terminal will make it snappy again. Using something like Alacritty will make it even snappier if you're sensitive to it.
- if you are on linux and use the gui, the pgtk branch is worth giving a try, it drops the old extremely outdated Xt code
- LSP can be quite resource hungry, it's really worth giving a try to the nativecomp branch of emacs 28. https://www.emacswiki.org/emacs/GccEmacs
- if you are on osx, you'll may find the gui rendering quite laggy if you are using a Retina display. Using the terminal will make it snappy again. Using something like Alacritty will make it even snappier if you're sensitive to it.
- if you are on linux and use the gui, the pgtk branch is worth giving a try, it drops the old extremely outdated Xt code
- LSP can be quite resource hungry, it's really worth giving a try to the nativecomp branch of emacs 28. https://www.emacswiki.org/emacs/GccEmacs
I have been using Emacs for several years now, I love how easy it makes it to quickly browse and edit code. The only downside is that coding without Emacs keybindings makes me uncomfortable and kind of sloppy. Fortunately most IDEs have an Emacs plugin.
I love emacs as a lisp environment to work in and have used it for 20 years but the emacs LSP picture is starting to look seriously sketchy in comparison with what more language-specific IDEs such as VSCode and PyCharm etc offer. Especially now that static typing is becoming standard in languages like Python and Javascript. If you have a lot of spare time you can probably make eglot and lsp-mode work in your favorite language. But if you work in a few languages, you sort of need to be working part time and have no family or social commitments.
My experience with lsp-mode is quite the opposite. I was able to configure it with rust-analyzer/gopls/pyright for half a day and I would say that it is very close to "just works". Previously I was using VScode and emacs only for org-mode.
My only experience with emacs is doom emacs, and only about 6 months, but I haven’t felt this pain other than getting the right formatter to format. I’m doing frontend react work so primarily tsx and sass, so maybe not a counterpoint but
Does it feel weird that you have to enable Evil mode to use emacs? I have been using Vim for most my life and switched to emacs last years. I am using vanilla version with lots of plugins of course.
Not really. Evil's vim emulation are quite impressive, and it's doing its best to make the bindings available everywhere in Emacs. However, the behavior of each keys in different buffers are somewhat less consistent than with Vim, which is inevitable because Emacs buffers are used more like an UI for elisp applications. I think the benefits far outweigh the minor inconsistencies though.
I started with emacs and never learned vim. What am I missing?
Vi's sense of composability. For example, 'd' is the delete command, but what does it delete? It deletes across a motion. What is a motion? Could be any movement mode supported by the editor, which ranges from simple cursor motions to motions involving words or blocks to forms of searching to raw line number jumps.
So, once you learn a vi command, you can use it with all the motions you already know, and once you learn a motion, you can use it with all the commands you already know.
The other aspect, that is more insidiously useful: vi is almost everywhere, and will easily fit on an embedded system. It's a rare server that doesn't have it, either. This is definitely vi, not vim, when I say this, though.
So, once you learn a vi command, you can use it with all the motions you already know, and once you learn a motion, you can use it with all the commands you already know.
The other aspect, that is more insidiously useful: vi is almost everywhere, and will easily fit on an embedded system. It's a rare server that doesn't have it, either. This is definitely vi, not vim, when I say this, though.
I've used vim for more than 20 years, but lately I'm finding that now that `prettier` and `black` can just reformat code wholesale, I don't have to care as much about the precise tiny edits that vim is so good at. And when I'm not worried about those things, I start to notice that modern IDEs have much smarter syntax checking and whole-project search than I've ever seen in vim, even with plugins. So I think I'm moving on.
then you might have missed coc.vim (vscode's full LSP for vim)
Yep, for me the peak right now is an IDE that has a great VIM plugin. You get the best part of vi (the insane productivity and wrist health increase that is modal editing) with all the best parts of a modern IDE.
I don't feel like I'm missing anything from a VIM-only setup in any way right now
I don't feel like I'm missing anything from a VIM-only setup in any way right now
I can relate. Going from Emacs to evil-mode (not pure vim) has been a bliss. Text and code editing feels almost like playing a game.
Totally agree about it feeling like playing a game. It’s probably because of the combos and just how fast things can be when you move around! I use neovim but I’m sure the experience we have is the same.
For me, using VSCode felt neat. Learning and using nvim felt fun. Learning and using doom emacs feels exciting.
A decent text editor
Modal editing.
Command mode lets you manipulate text using a full keyboard as shortcuts. Depending on setup this can reduce the amount of chording you do.
Visual mode lets you select text. By character, line, or region/block. I find this easier than emacs selection.
Insert mode what you use to enter text.
Command mode lets you manipulate text using a full keyboard as shortcuts. Depending on setup this can reduce the amount of chording you do.
Visual mode lets you select text. By character, line, or region/block. I find this easier than emacs selection.
Insert mode what you use to enter text.
Well he didn't say he was using Emacs with the default keybindings.
Emacs' evil-mode is used by many Emacs users who prefer modal editing...
Emacs' evil-mode is used by many Emacs users who prefer modal editing...
I am conversant with both. You are not really missing anything. I use vi when emacs is not already installed and I need to quickly edit a file. That's the main difference, for me. vi is already there, but emacs has to be installed.
I used vim for a decade and tried to switch to vanilla emacs.
I didn't like code navigation in emacs at all.
After a few weeks of fighting it, I switched to evil-mode emacs and was pretty happy since then.
After a few weeks of fighting it, I switched to evil-mode emacs and was pretty happy since then.
A different way of doing the same thing for text editing, on which both are great. I use evil-mode just because of muscle memory from vim.
I have been using a jetbrain IDE recently and surprisingly, the vim plugin is pretty decent. So knowing vim lets me use both the IDE and emacs with less friction.
I have been using a jetbrain IDE recently and surprisingly, the vim plugin is pretty decent. So knowing vim lets me use both the IDE and emacs with less friction.
Primarily the fact that vim is EVERYWHERE and starts up instantly with zero config, so it's great when you find yourself on J. Random Server and need to edit something. It's good to know some basic basics.
I'd like to ask the opposite question as someone who knows Vim but not Emacs. What am I missing if I'm only concerned with text editing?
stellar speed
If you switched from vim to evil-on-emacs, you didn't really switch to emacs. You switched to something akin to a best-of-both-worlds.
"Finally, install evil-mode, the Vim emulation package for Emacs"
Anyone use this regularly? Does it kill off some of the upside of emacs?
Anyone use this regularly? Does it kill off some of the upside of emacs?
Really, no. It's a huge portion of the user base of Emacs, and gets a lot of support. Might be a few issues here and there but highly surmountable and you'll be in company.
I don't use evil mode, but I don't see how it could kill any of the upside of Emacs, which has very little to do with keybindings.
Evil mode is very popular (see doom emacs or spacemacs which try to integrate lots of emacs extensions with evil mode on by default)
I use it regularly. It integrates quite well with emacs and if you use the evil-collection you can add vim-ness to other modes.
Personally, I mostly just use evil for modal editing, as I am a long time vim user. Then I use the emacs shortcuts on top of that.
Personally, I mostly just use evil for modal editing, as I am a long time vim user. Then I use the emacs shortcuts on top of that.
Recently, I too tried making the switch from vim to Emacs via the Spacemacs route. The effort didn't last long. I found that Spacemacs, without installing any extra "layers" than what comes out of the box, consumes too much RAM. Over 1GB of it. Don't know if this was expected or if it was something specific to just my machine.
May I advise to give a try to Doom instead? It has less ambitious objectives [1] and feels much snappier while providing a similar experience (vim-like, out of the box)
Also, if you enjoy the experience provided by emacs + evil, giving a try to the native compilation branch of emacs 28 gives noticeable improvement in terms of speed.
[1] Spacemacs "it's a sophisticated and polished set-up, focused on ergonomics, mnemonics and consistency" VS being focused on speed, https://github.com/hlissner/doom-emacs#introduction
Also, if you enjoy the experience provided by emacs + evil, giving a try to the native compilation branch of emacs 28 gives noticeable improvement in terms of speed.
[1] Spacemacs "it's a sophisticated and polished set-up, focused on ergonomics, mnemonics and consistency" VS being focused on speed, https://github.com/hlissner/doom-emacs#introduction
Thanks for taking the time to give a detailed recommendation. Setting up Doom right now!
[deleted]
I’m curious to hear from folks who have switched between the two, and have lasted for more than a year on both. If you’ve learned more than the basics and both became muscle memory, which did you end up sticking to?
(Vim user for 23 years, Emacs user of none... but interested because of Lisp)
(Vim user for 23 years, Emacs user of none... but interested because of Lisp)
Vim user for 12 years, Emacs user for 5. I prefer and mainly use Emacs after I finally "got it". My previous attempts at learning Emacs weren't as successful because I was too biased about what a good editor should be like because of my familiarity with vim - mainly I was annoyed about silly things like having to press 4 keypresses for tasks that would take two keypresses in vim. So, if you decide to give Emacs a try, keep your preconceptions away and accept that it will take months before you "get" Emacs, the same way it probably took months before you "got" vim.
I still use vim when I am at a new system or on a remote server, but Emacs is love, Emacs is home. It is the most open, discoverable and hackable software system I have ever used. Every action, button, keybinding is easily introspectable - and it takes only a few clicks to get even to the source of the functionality that you are interested in. Almost every aspect of this system is modifiable by the user, even on the fly.
The only downside is that it is so much fun to play with your emacs config that you might spend too much time doing that instead of productive work. By contrast, vimscript is so disgusting that I don't think that I ever wrote a single line of vim config that wasn't copy-pasted from somewhere.
I still use vim when I am at a new system or on a remote server, but Emacs is love, Emacs is home. It is the most open, discoverable and hackable software system I have ever used. Every action, button, keybinding is easily introspectable - and it takes only a few clicks to get even to the source of the functionality that you are interested in. Almost every aspect of this system is modifiable by the user, even on the fly.
The only downside is that it is so much fun to play with your emacs config that you might spend too much time doing that instead of productive work. By contrast, vimscript is so disgusting that I don't think that I ever wrote a single line of vim config that wasn't copy-pasted from somewhere.
Thanks for that... you seemed to be future me, and it sounds exciting!
do you think this always praised evil-mode feels natural to a vimmer or feels like something close but yeah, not great like all vim emulations in all other editos?
I was a vim user for 16 years (very proficient -- other developers in whatever office I was in would ask me vim questions) when I switched to emacs about 8 years ago. I switched for curiousity and to check out evil mode and magit.
A couple years ago during a lull in a dev cycle I built a neovim setup to see the state of that art but I didn't stick with it.
I've rewritten my emacs configuration many times, swapped between spacemacs, vanilla, and doom. I am currently on doom emacs with my customizations.
I also do not use evil mode anymore. Default emacs bindings make a lot of sense to me. I can still use vim with muscle memory, but I reach for "mg" if I need a quick edit more often than not.
A couple years ago during a lull in a dev cycle I built a neovim setup to see the state of that art but I didn't stick with it.
I've rewritten my emacs configuration many times, swapped between spacemacs, vanilla, and doom. I am currently on doom emacs with my customizations.
I also do not use evil mode anymore. Default emacs bindings make a lot of sense to me. I can still use vim with muscle memory, but I reach for "mg" if I need a quick edit more often than not.
I'll just say if you want to do Common Lisp, vim works fine, so don't let that hold you back from pursuing your interest. The slimv plugin is good. (Some people also like vlime better. To be honest I've had some buggy experiences with both, I suggest try both and pick what you like. vlime has one debugging improvement in that you don't need to manually call (swank-backend:restart-frame N).)
I'd like to give emacs one more chance, but haven't gotten around to it. Last time I tried Spacemacs (for about a month, sorry not a year) and ultimately didn't like it, I'm planning on trying Doom Emacs next.
I'd like to give emacs one more chance, but haven't gotten around to it. Last time I tried Spacemacs (for about a month, sorry not a year) and ultimately didn't like it, I'm planning on trying Doom Emacs next.
> I'll just say if you want to do Common Lisp, vim works fine, so don't let that hold you back from pursuing your interest.
I agree. For those who are interested in using Vim as their development environment for Common Lisp, I have written a detailed comparison between Slimv and Vlime here: https://susam.in/blog/lisp-in-vim-with-slimv-or-vlime/
And for those who are willing to start Common Lisp development using Emacs, there is Portacle which is a really quick way to set up a working environment with a few clicks. There is also https://github.com/susam/emacs4cl that I wrote to offer as a quick-starter DIY alternative for those who want to use vanilla Emacs and want to configure it themselves without wasting too much time.
I agree. For those who are interested in using Vim as their development environment for Common Lisp, I have written a detailed comparison between Slimv and Vlime here: https://susam.in/blog/lisp-in-vim-with-slimv-or-vlime/
And for those who are willing to start Common Lisp development using Emacs, there is Portacle which is a really quick way to set up a working environment with a few clicks. There is also https://github.com/susam/emacs4cl that I wrote to offer as a quick-starter DIY alternative for those who want to use vanilla Emacs and want to configure it themselves without wasting too much time.
In the 90s I used both editors interchangeably depending on the task (I had started with plain vi before vim). I was only grasping the surface of Emacs back then: I typically used it for editing plain text, emails, or scientific papers, but not as an OS or lisp system. I wrote code in either vim or Emacs without a clear preference, and sometimes I got annoyed at the extra milliseconds latency of starting emacsclient compared to starting vi. Once the majority of my terminals and shells were within emacs, I started favoring it. Once I realized that I strongly prefer to have several dozens, even hundreds of dumb terminal buffers with infinite history instead of proper terminals that can use curses but lack the complete past history, I switched to 95% Emacs, and I started keeping emacs sessions open for months at a time. Then I read the manual again, learned some elisp, added a couple convenience functions, and got totally hooked. Nowadays I may use vim once every couple of months, but the vast majority of my working time is within Emacs. Recently, I've started exploring ways to include part of web browsing in emacs, and I started wondering if most of my daily compute needs could be satisfied within Emacs. I guess that until I have a reasonable emacs interface on my phone, I will still spend some computer time outside of Emacs, but be warned that once you enter the Emacs cult, there is no easy way to exit.
I would say that what areally changes the game is to use evil (vi style bindings, 95% stays the same) with Emacs so you keep the muscle memory and you can keep making use of the common ex commands.
I have gone back and forth between vim and emacs, usually for a bunch of years each time before currently settling on emacs with Doom. With the nativecomp branch, it's actually pretty snappy and doom emacs is a great setup to get started without drowning in the amount of configuration.
I would say that I just love vim style input and modal editing, but doing that on top of emacs with evil mode and elisp is a better match for me than vimscript. The feedback loop you get with LISP and emacs is incredible when tweaking things to your liking.
Every function is accessible, there is just a global scope and you can call pretty much anything. It's sounds like an horrible idea, but it also means you can quickly hack stuff by reusing the internals of a package you like.
For example, it took me half an hour to initially POC this https://github.com/jhchabran/ivy-lsp-current-buffer-symbols by just skimming through the emacs-lsp codebase and randomly trying funcs in the repl to get an idea of what each function was doing.
I have gone back and forth between vim and emacs, usually for a bunch of years each time before currently settling on emacs with Doom. With the nativecomp branch, it's actually pretty snappy and doom emacs is a great setup to get started without drowning in the amount of configuration.
I would say that I just love vim style input and modal editing, but doing that on top of emacs with evil mode and elisp is a better match for me than vimscript. The feedback loop you get with LISP and emacs is incredible when tweaking things to your liking.
Every function is accessible, there is just a global scope and you can call pretty much anything. It's sounds like an horrible idea, but it also means you can quickly hack stuff by reusing the internals of a package you like.
For example, it took me half an hour to initially POC this https://github.com/jhchabran/ivy-lsp-current-buffer-symbols by just skimming through the emacs-lsp codebase and randomly trying funcs in the repl to get an idea of what each function was doing.
I have used both daily for over a year (and emacs alone for a few years). Once I was used to vim, I started using evil in emacs. So, at least in reference to muscle memory, I ended up sticking with vim. The thing is, evil is a mostly complete vim implementation. If I were forced to choose one editor, it would definitely be emacs.
I’m a nvim user of 2 years, a doom emacs user of 6 months. I don’t intend to go back to nvim because org mode is just too wonderful, and doom emacs does a great job of making emacs speedy, though of course it could never be as speedy as vim, I rarely notice it
The distinction with regard to muscle memory between Vim and evil-mode Emacs is a false one. Try Doom or Spacemacs. You are likely to learn more about your editor and your development process with a tool like Spacemacs.
Emacs user for the years in college, with the occasional forced dip into vi.
Vim user for ten years after college with a couple of forced dips into Eclipse and other IDEs, with vi keybindings where available.
Evil emacs user for about the last ten years. Magit makes me happy. Tramp wins the "but vi is everywhere" conversation. Org-mode wins.
I won't hire someone unwilling to give emacs an honest effort. Switching back to emacs remains the best professional decision I have made.
Vim user for ten years after college with a couple of forced dips into Eclipse and other IDEs, with vi keybindings where available.
Evil emacs user for about the last ten years. Magit makes me happy. Tramp wins the "but vi is everywhere" conversation. Org-mode wins.
I won't hire someone unwilling to give emacs an honest effort. Switching back to emacs remains the best professional decision I have made.
I won't hire someone unwilling to give emacs an honest effort.
An employer has no business dictating what text editor their employees use, if they're productive.
An employer has no business dictating what text editor their employees use, if they're productive.
I have been using emacs like forever. Finally decided to learn vim 4 years back, as had to use Intellij Idea, and the default keybindings are crap for editing. Now, I use Doom Emacs with evil keybindings.
I am glad I took time to learn vim. The editing concepts around motion keys, text blocks etc. are just so much more powerful than emacs way.
I recommend all emacs users to learn vim atleast give evil mode a try.
I am glad I took time to learn vim. The editing concepts around motion keys, text blocks etc. are just so much more powerful than emacs way.
I recommend all emacs users to learn vim atleast give evil mode a try.
There are not as far apart as I thought https://trends.google.com/trends/explore?date=all&geo=US&q=v...
From Vim or Emacs to Nano in fourteen minutes...
wouldn't this just be....
How to go from Vim to any other Editor/IDE and use Vim bindings ...
How to go from Vim to any other Editor/IDE and use Vim bindings ...
What is this new-fangled Emacs??
WordStar ought to be enough for anybody!
WordStar ought to be enough for anybody!
Emacs is older than Wordstar.
> Emacs is older than Wordstar.
True, but only because Emacs is older than God :-)
(They say they used parenthesis, but it was just snippets of Perl everywhere: https://xkcd.com/224/)
True, but only because Emacs is older than God :-)
(They say they used parenthesis, but it was just snippets of Perl everywhere: https://xkcd.com/224/)
email sig:
In the beginning was the lambda, and the lambda was with Emacs, and Emacs was the lambda.
In the beginning was the lambda, and the lambda was with Emacs, and Emacs was the lambda.
Probably took 12 of those 14 days to just get Emacs loaded. Just saying.
After over a decade of Vim, I’m hooked on Emacs - https://news.ycombinator.com/item?id=16551796 - March 2018 (161 comments)
A pragmatic decision on GNU Emacs versus Vim for programming - https://news.ycombinator.com/item?id=13590944 - Feb 2017 (59 comments)
Why I switched from Vim to Emacs - https://news.ycombinator.com/item?id=13130775 - Dec 2016 (101 comments)
From Vim to Emacs - https://news.ycombinator.com/item?id=8367384 - Sept 2014 (116 comments)
Emacs and Vim - https://news.ycombinator.com/item?id=8084359 - July 2014 (275 comments)
Vi and Vim vs. Emacs Shootout and Deal - https://news.ycombinator.com/item?id=3205828 - Nov 2011 (52 comments)
Some thoughts on Emacs and Vim - https://news.ycombinator.com/item?id=2229040 - Feb 2011 (40 comments)
How a Vim user converts to Emacs - https://news.ycombinator.com/item?id=2036586 - Dec 2010 (66 comments)
On vim vs emacs - https://news.ycombinator.com/item?id=1374916 - May 2010 (28 comments)
Debian's Vim maintainer switches to Emacs - https://news.ycombinator.com/item?id=341492 - Oct 2008 (32 comments)