[andrewzah]

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.

[alex_smart]

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.

[bern4444]

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.

[hackerbrother]

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.)

[colordrops]

It's certainly easier than editing an XMonad config without knowing Haskell.

[jrockway]

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.

[colordrops]

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.

[thelean12]

> 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.

[andrewzah]

"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.

[zshev]

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...

[ryukafalz]

> 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.)

[zwegner]

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.

[jeromenerf]

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.

[e12e]

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).

[spudlyo]

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

[jeromenerf]

Thanks for this video, this is the one I link to when asked for a Babel demo.

[boogies]

> 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.

[flowerlad]

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).

[ithrow]

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?

[flowerlad]

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.

[soraminazuki]

> 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.

[Cyph0n]

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

[flowerlad]

> 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.

[kagevf]

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.

[thewakalix]

That depends on what the meaning of "everywhere" is.

[nix-zarathustra]

He actually has a talk about it: https://www.youtube.com/watch?v=JWD1Fpdd4Pc

[asciimov]

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.

[weaksauce]

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.