Design philosophies of Vim vs Emacs - Revision history

Issa at 02:58, 16 January 2026

2026-01-16T02:58:31Z

Issa: /* Tree-based undo vs stack-based undo */

2025-12-22T03:26:14Z

‎Tree-based undo vs stack-based undo

Issa: /* Multiple similar commands vs single repeated command */

2025-12-22T03:24:25Z

‎Multiple similar commands vs single repeated command

Issa: /* Modal vs chording */

2025-12-09T23:38:50Z

‎Modal vs chording

Issa: /* Modal vs chording */

2025-12-09T23:37:44Z

‎Modal vs chording

Issa: /* Modal vs chording */

2025-12-09T23:35:42Z

‎Modal vs chording

Issa: /* Modal vs chording */

2025-12-09T23:32:53Z

‎Modal vs chording

Issa at 19:36, 6 December 2025

2025-12-06T19:36:32Z

Issa: /* Modal vs chording */

2025-12-04T21:29:40Z

‎Modal vs chording

Issa: /* Mappings: keystroke based vs function-based */

2025-12-04T21:22:05Z

‎Mappings: keystroke based vs function-based

← Older revision		Revision as of 02:58, 16 January 2026
Line 107:		Line 107:

	Vim includes the selection endpoint, whereas Emacs doesn't. The need to make this decision comes from both editors originating on the terminal with block cursors, rather than the more modern I-beam cursors.		Vim includes the selection endpoint, whereas Emacs doesn't. The need to make this decision comes from both editors originating on the terminal with block cursors, rather than the more modern I-beam cursors.
		+
		+	==Messages: clear as late as possible/explicitly vs clear as soon as possible==
		+
		+	Vim only clears messages when the user does ctrl-l or does something that would redraw the screen somehow. Emacs clears as soon as the cursor is moved.

	[[Category:Design]]		[[Category:Design]]

← Older revision		Revision as of 03:26, 22 December 2025
Line 45:		Line 45:

	==Tree-based undo vs stack-based undo==		==Tree-based undo vs stack-based undo==
		+
		+	(I think the mark ring in Emacs is also stack-based.)

	==Multiple similar commands vs single repeated command==		==Multiple similar commands vs single repeated command==

@@ Line 59: / Line 59: @@
 * Text formatting: Vim gives you two operators, gq and gw, which format text; gq moves the cursor to the end of the formatted text, while gw tries to keep the cursor where it was before the formatting. You can then combine these operators with any motion, e.g. gwip to format the current paragraph, gww to format the current line, gwib to format inside parentheses. Emacs just gives you Alt-q to format the paragraph. It is then up to you to creatively combine that with text selection; you can select some text and then do Alt-q to format just the text that is selected.
 * Copy-pasting: Vim gives you named registers, so if you want to copy two different lines and remember both, you do something like <code>"ayy</code> and <code>"byy</code>; then you can paste them with <code>"ap</code> and <code>"bp</code>. In Emacs, you instead kill both lines, and then when you go to paste them, you first Ctrl-y to paste the most recent, and then you do Alt-y to cycle between the most recently killed text.
 * Vim has j and k to move down and up by logical lines, and also has gj and gk to move down and up by screen-lines. Emacs only has Ctrl-n and Ctrl-p to move down and up by screen-lines. To move by logical lines, you need to do something creative like Ctrl-e Ctrl-f or Ctrl-a Ctrl-b, or just repeatedly press Ctrl-n or Ctrl-p.
 In general, I feel that Vim requires more mental energy to use (by forcing the user to pick the action more precisely, and by having the user plan ahead). You need to pick the specific action you wanted to perform. You need to think ahead and decide which registers to use. This also comes from Vim's modal nature, but Vim gives you more decisions and a grammar, whereas Emacs gives you a way to quickly do the common thing. I think much of this may have been forced on the design of Vim by deciding to be keystroke-based, so that the only way to make some action available in normal mode was to assign some key to it. Whereas Emacs went more in the direction of being functions-first, and once you have functions, it is natural to pass arguments to the function to modify the behavior.

@@ Line 4: / Line 4: @@
 * Atomic edits and the dot command in Vim: When you use Vim, you naturally start to think in terms of repeatable edits that you can then use the <code>.</code> command to repeat. But this has a side-effect in that Vim requires you to manually chunk your undo history. Emacs instead automatically chunks undos.
 * One consequence of the modal editing is that I think Vim degrades gracefully to having worse keyboards/a less ergonomic setup in general ([https://youtu.be/SY8L-cj4x6k?t=3594 or big hands]). For example, I bought a fairly crappy external USB keyboard for $25 where if I don't press the Ctrl key very firmly, sometimes it will not register. This hasn't been a problem in most software, but ''has'' become a problem when I use Emacs because I need to hold down the Ctrl key a lot for navigating with Ctrl+p and Ctrl+n. In Vim, I don't have this problem at all because Ctrl just isn't a key I need to hold down for long periods; it's something I momentarily hold down, just long enough to press another key. So I have never run into this problem when using Vim (or even Firefox or other software). Emacs is the editor, and really only software, that in some sense ''requires'' me to have a nice keyboard.
-* Another consequence of modal editing (in particular, the fact that Vi decided to use the escape key as the modal switch to move out of insert and command-line modes) is that since escape is also use in terminal escape sequences, now there is a conflict in interpreting key sequences containing the escape key: is it the user switching out of insert mode and typing some normal-mode commands? Or is it the start of a terminal escape sequence (e.g. use of the arrow keys)? Because of this, Vim added options like ttimeout, ttimeoutlen, esckeys, and probably more, and tmux also has an option called escape-time which used to be necessary to set. If these options are not set correctly, one may have to wait up to 1-3 seconds for the effect of typing an escape key to show up on screen (because without waiting, Vim is not sure if you meant to just type an escape key or if you typed something that began a terminal escape sequence). It also means that unlike in all other terminal applications, you cannot easily use alt-key bindings, and in particular you cannot do the esc-key alternative to send an alt-key binding. If Vim had chosen literally any other key to represent mode switching (such as Ctrl-c, or maybe Ctrl-z which is used in evil-mode on Emacs to toggle between Vim-mode and Emacs-mode), this would not have been a problem. (Not to mention that if such a replacement key was chosen well, it would have been easier to type than Ctrl-[ or the escape key, since the escape key on modern keyboards is far from the home row of the keyboard!) Modern terminals like Kitty, and also Neovim, are finally fixing this so that you don't have to ever think about this anymore. But there is still a sort of burden I feel from years of Vim use.
+* Another consequence of modal editing (in particular, the fact that Vi decided to use the escape key as the modal switch to move out of insert and command-line modes) is that since escape is also use in terminal escape sequences, now there is a conflict in interpreting key sequences containing the escape key: is it the user switching out of insert mode and typing some normal-mode commands? Or is it the start of a terminal escape sequence (e.g. use of the arrow keys)? Because of this, Vim added options like ttimeout, ttimeoutlen, esckeys, and probably more, and tmux also has an option called escape-time which used to be necessary to set. If these options are not set correctly, one may have to wait up to 1-3 seconds for the effect of typing an escape key to show up on screen (because without waiting, Vim is not sure if you meant to just type an escape key or if you typed something that began a terminal escape sequence). It also means that unlike in all other terminal applications, you cannot easily use alt-key bindings, and in particular you cannot do the esc-key alternative to send an alt-key binding. If Vim had chosen literally any other key to represent mode switching (such as Ctrl-c, or maybe Ctrl-z which is used in evil-mode on Emacs to toggle between Vim-mode and Emacs-mode), this would not have been a problem. (Not to mention that if such a replacement key was chosen well, it would have been easier to type than Ctrl-[ or the escape key, since the escape key on modern keyboards is far from the home row of the keyboard and the left-square-bracket is vaguely hard to reach for!) Modern terminals like Kitty, and also Neovim, are finally fixing this so that you don't have to ever think about this anymore. But there is still a sort of burden I feel from years of Vim use.
 ==Unix as IDE vs Emacs as OS==

@@ Line 4: / Line 4: @@
 * Atomic edits and the dot command in Vim: When you use Vim, you naturally start to think in terms of repeatable edits that you can then use the <code>.</code> command to repeat. But this has a side-effect in that Vim requires you to manually chunk your undo history. Emacs instead automatically chunks undos.
 * One consequence of the modal editing is that I think Vim degrades gracefully to having worse keyboards/a less ergonomic setup in general ([https://youtu.be/SY8L-cj4x6k?t=3594 or big hands]). For example, I bought a fairly crappy external USB keyboard for $25 where if I don't press the Ctrl key very firmly, sometimes it will not register. This hasn't been a problem in most software, but ''has'' become a problem when I use Emacs because I need to hold down the Ctrl key a lot for navigating with Ctrl+p and Ctrl+n. In Vim, I don't have this problem at all because Ctrl just isn't a key I need to hold down for long periods; it's something I momentarily hold down, just long enough to press another key. So I have never run into this problem when using Vim (or even Firefox or other software). Emacs is the editor, and really only software, that in some sense ''requires'' me to have a nice keyboard.
-* Another consequence of modal editing (in particular, the fact that Vi decided to use the escape key as the modal switch to move out of insert and command-line modes) is that since escape is also use in terminal escape sequences, now there is a conflict in interpreting key sequences containing the escape key: is it the user switching out of insert mode and typing some normal-mode commands? Or is it the start of a terminal escape sequence (e.g. use of the arrow keys)? Because of this, Vim added options like ttimeout, ttimeoutlen, esckeys, and probably more, and tmux also has an option called escape-time which used to be necessary to set. If these options are not set correctly, one may have to wait up to 1-3 seconds for the effect of typing an escape key to show up on screen (because without waiting, Vim is not sure if you meant to just type an escape key or if you typed something that began a terminal escape sequence). It also means that unlike in all other terminal applications, you cannot easily use alt-key bindings, and in particular you cannot do the esc-key alternative to send an alt-key binding. If Vim had chosen literally any other key to represent mode switching (such as Ctrl-c, or maybe Ctrl-z which is used in evil-mode on Emacs to toggle between Vim-mode and Emacs-mode), this would not have been a problem. Modern terminals like Kitty, and also Neovim, are finally fixing this so that you don't have to ever think about this anymore. But there is still a sort of burden I feel from years of Vim use.
+* Another consequence of modal editing (in particular, the fact that Vi decided to use the escape key as the modal switch to move out of insert and command-line modes) is that since escape is also use in terminal escape sequences, now there is a conflict in interpreting key sequences containing the escape key: is it the user switching out of insert mode and typing some normal-mode commands? Or is it the start of a terminal escape sequence (e.g. use of the arrow keys)? Because of this, Vim added options like ttimeout, ttimeoutlen, esckeys, and probably more, and tmux also has an option called escape-time which used to be necessary to set. If these options are not set correctly, one may have to wait up to 1-3 seconds for the effect of typing an escape key to show up on screen (because without waiting, Vim is not sure if you meant to just type an escape key or if you typed something that began a terminal escape sequence). It also means that unlike in all other terminal applications, you cannot easily use alt-key bindings, and in particular you cannot do the esc-key alternative to send an alt-key binding. If Vim had chosen literally any other key to represent mode switching (such as Ctrl-c, or maybe Ctrl-z which is used in evil-mode on Emacs to toggle between Vim-mode and Emacs-mode), this would not have been a problem. (Not to mention that if such a replacement key was chosen well, it would have been easier to type than Ctrl-[ or the escape key, since the escape key on modern keyboards is far from the home row of the keyboard!) Modern terminals like Kitty, and also Neovim, are finally fixing this so that you don't have to ever think about this anymore. But there is still a sort of burden I feel from years of Vim use.
 ==Unix as IDE vs Emacs as OS==

← Older revision		Revision as of 19:36, 6 December 2025
Line 103:		Line 103:

	Vim includes the selection endpoint, whereas Emacs doesn't. The need to make this decision comes from both editors originating on the terminal with block cursors, rather than the more modern I-beam cursors.		Vim includes the selection endpoint, whereas Emacs doesn't. The need to make this decision comes from both editors originating on the terminal with block cursors, rather than the more modern I-beam cursors.
		+
		+	[[Category:Design]]

@@ Line 35: / Line 35: @@
 In Emacs, every keystroke, even entering a single character, has a function that is associated with it. Emacs is simply an interpreter that runs the function associated with the keystroke. You can always do Ctrl-h k followed by the keystroke to find which function is bound to that particular keystroke.
-I think that being keystroke-based is one of the reasons Vim is so conservative about default keybindings, because if you change the default keybinding inside of the C source code, it actually breaks all user mappings and scripts that rely on replaying keystrokes. So then eventually Vim came up with defaults.vim, which is not implemented on the level of C, but instead implemented on the level of Vimscript. By implementing it in Vimscript, it functions like user configuration, so it doesn't change what the original keybindings mean. But doing this also means now you have to reason about multiple levels, the "base layer C keybindings" vs the "default keybindings that you actually interact with". And at that point you've kind of reinvented the thing that Emacs does.
+I think that being keystroke-based is one of the reasons Vim is so conservative about default keybindings (even when they are terrible, like Ctrl-b to go to the beginning of the line in command-line mode, or Y to copy the entire line instead of copying to the end of the line), because if you change the default keybinding inside of the C source code, it actually breaks all user mappings and scripts that rely on replaying keystrokes. So then eventually Vim came up with defaults.vim, which is not implemented on the level of C, but instead implemented on the level of Vimscript. By implementing it in Vimscript, it functions like user configuration, so it doesn't change what the original keybindings mean. But doing this also means now you have to reason about multiple levels, the "base layer C keybindings" vs the "default keybindings that you actually interact with". And at that point you've kind of reinvented the thing that Emacs does.
 ==Actions: commands vs keybindings==