Issawiki - User contributions [en]

Design philosophies of Vim vs Emacs

2026-01-16T02:58:31Z

Issa:

==Modal vs chording==

* 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 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==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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 (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==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

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

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Indenting: The way TAB indenting works in Emacs is very distinctive. You press TAB and Emacs just indents the line to whatever it thinks is the right level. Vim's TAB in insert mode just inserts a literal tab or spaces depending on the 'expandtab' option. But Vim also gives you, in insert mode, Ctrl-f to do the Emacs-like thing, Ctrl-t to indent the current line, Ctrl-d to decrease the indent of the current line. And many more commands in normal mode.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.
* Probably another manifestation of this is that Vim has a jump list, a change list, and a tag stack. Whereas I think Emacs only has a mark ring.

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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No line numbers, sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

Both Vim and Emacs have prominent comment colors in their syntax highlighting by default (in Vim it's blue, in Emacs it's red), which I think says a lot. By making most things invisible but making comments stand out, it tells the user that comments are something worth paying attention to. They both come from a saner culture in which programmers were intelligent and comments meant something. Now modern editors have all this crap in your face, and not just that, they make comments ''grayed out'' so that they almost fade into the background (VS Code is the one exception, where its default colorscheme has green comments).

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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

Design philosophies of Vim vs Emacs

2025-12-22T03:26:14Z

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

Design philosophies of Vim vs Emacs

2025-12-22T03:24:25Z

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

==Modal vs chording==

* 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 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==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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 (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==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Indenting: The way TAB indenting works in Emacs is very distinctive. You press TAB and Emacs just indents the line to whatever it thinks is the right level. Vim's TAB in insert mode just inserts a literal tab or spaces depending on the 'expandtab' option. But Vim also gives you, in insert mode, Ctrl-f to do the Emacs-like thing, Ctrl-t to indent the current line, Ctrl-d to decrease the indent of the current line. And many more commands in normal mode.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.
* Probably another manifestation of this is that Vim has a jump list, a change list, and a tag stack. Whereas I think Emacs only has a mark ring.

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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No line numbers, sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

Both Vim and Emacs have prominent comment colors in their syntax highlighting by default (in Vim it's blue, in Emacs it's red), which I think says a lot. By making most things invisible but making comments stand out, it tells the user that comments are something worth paying attention to. They both come from a saner culture in which programmers were intelligent and comments meant something. Now modern editors have all this crap in your face, and not just that, they make comments ''grayed out'' so that they almost fade into the background (VS Code is the one exception, where its default colorscheme has green comments).

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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

Design philosophies of Vim vs Emacs

2025-12-09T23:38:50Z

Issa: /* Modal vs chording */

==Modal vs chording==

* 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 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==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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 (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==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Indenting: The way TAB indenting works in Emacs is very distinctive. You press TAB and Emacs just indents the line to whatever it thinks is the right level. Vim's TAB in insert mode just inserts a literal tab or spaces depending on the 'expandtab' option. But Vim also gives you, in insert mode, Ctrl-f to do the Emacs-like thing, Ctrl-t to indent the current line, Ctrl-d to decrease the indent of the current line. And many more commands in normal mode.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No line numbers, sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

Both Vim and Emacs have prominent comment colors in their syntax highlighting by default (in Vim it's blue, in Emacs it's red), which I think says a lot. By making most things invisible but making comments stand out, it tells the user that comments are something worth paying attention to. They both come from a saner culture in which programmers were intelligent and comments meant something. Now modern editors have all this crap in your face, and not just that, they make comments ''grayed out'' so that they almost fade into the background (VS Code is the one exception, where its default colorscheme has green comments).

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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

Design philosophies of Vim vs Emacs

2025-12-09T23:37:44Z

Issa: /* Modal vs chording */

==Modal vs chording==

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

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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 (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==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Indenting: The way TAB indenting works in Emacs is very distinctive. You press TAB and Emacs just indents the line to whatever it thinks is the right level. Vim's TAB in insert mode just inserts a literal tab or spaces depending on the 'expandtab' option. But Vim also gives you, in insert mode, Ctrl-f to do the Emacs-like thing, Ctrl-t to indent the current line, Ctrl-d to decrease the indent of the current line. And many more commands in normal mode.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No line numbers, sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

Both Vim and Emacs have prominent comment colors in their syntax highlighting by default (in Vim it's blue, in Emacs it's red), which I think says a lot. By making most things invisible but making comments stand out, it tells the user that comments are something worth paying attention to. They both come from a saner culture in which programmers were intelligent and comments meant something. Now modern editors have all this crap in your face, and not just that, they make comments ''grayed out'' so that they almost fade into the background (VS Code is the one exception, where its default colorscheme has green comments).

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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

Design philosophies of Vim vs Emacs

2025-12-09T23:35:42Z

Issa: /* Modal vs chording */

==Modal vs chording==

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

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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 (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==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Indenting: The way TAB indenting works in Emacs is very distinctive. You press TAB and Emacs just indents the line to whatever it thinks is the right level. Vim's TAB in insert mode just inserts a literal tab or spaces depending on the 'expandtab' option. But Vim also gives you, in insert mode, Ctrl-f to do the Emacs-like thing, Ctrl-t to indent the current line, Ctrl-d to decrease the indent of the current line. And many more commands in normal mode.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No line numbers, sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

Both Vim and Emacs have prominent comment colors in their syntax highlighting by default (in Vim it's blue, in Emacs it's red), which I think says a lot. By making most things invisible but making comments stand out, it tells the user that comments are something worth paying attention to. They both come from a saner culture in which programmers were intelligent and comments meant something. Now modern editors have all this crap in your face, and not just that, they make comments ''grayed out'' so that they almost fade into the background (VS Code is the one exception, where its default colorscheme has green comments).

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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

Design philosophies of Vim vs Emacs

2025-12-09T23:32:53Z

Issa: /* Modal vs chording */

==Modal vs chording==

* 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 and ttimeoutlen, and tmux also has an option called escape-time. 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.

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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 (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==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Indenting: The way TAB indenting works in Emacs is very distinctive. You press TAB and Emacs just indents the line to whatever it thinks is the right level. Vim's TAB in insert mode just inserts a literal tab or spaces depending on the 'expandtab' option. But Vim also gives you, in insert mode, Ctrl-f to do the Emacs-like thing, Ctrl-t to indent the current line, Ctrl-d to decrease the indent of the current line. And many more commands in normal mode.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No line numbers, sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

Both Vim and Emacs have prominent comment colors in their syntax highlighting by default (in Vim it's blue, in Emacs it's red), which I think says a lot. By making most things invisible but making comments stand out, it tells the user that comments are something worth paying attention to. They both come from a saner culture in which programmers were intelligent and comments meant something. Now modern editors have all this crap in your face, and not just that, they make comments ''grayed out'' so that they almost fade into the background (VS Code is the one exception, where its default colorscheme has green comments).

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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

Main Page

2025-12-06T20:21:07Z

Issa:

The main things that are going on here:

* [[:Category:AI safety]] -- notes on AI safety strategy
* [[:Category:Spaced repetition]] -- detailing my approach to using spaced repetition software
* [[:Category:Learning]] -- pages about learning that aren't about spaced repetition
* [[:Category:Design]] -- pages about UI/UX design

For math, see [https://machinelearning.subwiki.org/wiki/User:IssaRice my ML Subwiki userspace pages].

For more on learning, see [https://learning.subwiki.org/w/index.php?title=Special:Contributions&limit=500&contribs=user&target=Issa+Rice&newOnly=1 my page creations on the Learning Subwiki].

Plugins as search

2025-12-06T20:18:47Z

Issa:

Similarly to how a programming language should strive to incorporate all useful features into itself, instead of making the user meta-program their way into a usable language, a PDF reader or any application should strive to just simply internalize all the useful features, instead of forcing users to script on features in predictably hacky ways. But how do you know which features are useful to incorporate?

A designer of the program somehow "magically, creatively" comes up with a list of features to include in the program. Maybe they have experience with an existing program of the same type (e.g. if they are designing a new text editor, they probably have experience using an existing text editor), so they know what they are looking to add to their own program. But that only raises the question, how did the designer of the original program of that type come up with a list of features? And if you are designing a program, you probably are looking to include some ''new'' features that do not exist in any program. So how do you come up with those?

I won't answer that general "What is creativity?" question here. But I want to make the observation that this sort of thing probably, most of the time, happens ''incrementally'', so that at any given moment, a given designer only comes up with one new feature, one thing to tweak, one aspect to change. (Of course, by the time a new piece of software ships, it might have many such features included within it, so that from the public's point of view, it might seem revolutionary. I am here only talking about what the creative process looks like internally.)

If we take this incremental view of creativity seriously, it becomes obvious that no single person has "all the answers" to design.

[not quite sure how to connect the above to the below...]

I've come to view plugins as one way of making the search process for features more parallelized. It would be "better" for the end-user-experience if all features were built into the main application from the start; this provides a smoother experience because plugins necessarily don't have access to program internals etc., so can't provide the features in a fully native way. Plugins are also often buggy because they don't have the same level of quality control as the main application. But it is impossible to armchair your way into a good design for your software! There is just no way to know which features are useful without getting feedback. Some way to quickly hack together a proof of concept idea without having to mess with the internals and source code of the main program would be useful. (Imagine needing to dig into Vim's C source code to be able to add a new feature!)

Instead of the designer of the program having to come up with and implement all features, users of the program can script things onto the program. Seeing which plugins are popular among users provides evidence for which features are actually useful.

It's hard to develop things into the main application, and because it's hard to experiment with trying out different features, plugins are the main way in which you can run experiments out in the wild, to figure out what users want/what's popular, and then the main application can take the results of such experiments and implement the best ones. In other words, plugin make it easier to search the space of all possible improvements to make to the main application. So I mainly see plugins as this somewhat expensive way to get data on what works.

People who praise the Helix editor for internalizing things like LSP, treesitter, etc., (but Helix doesn't have a plugin system) are sort of missing the point here; like, yes, it would be better for the editor to come bundled with all the nice features that users might want, but the only reason Helix is even able to do this in the first place is that there was things like Vim and VS Code and so forth that had a plugin system that allowed for these things to come into existence to be played around with. Without that ability to easily search for what is useful, something like Helix just couldn't even exist.

[[Category:Design]]

Category:Design

2025-12-06T20:08:37Z

Issa:

Pages about design, mostly design of software (in the UI/UX sense, not in the software architecture sense).

Plugins as search

2025-12-06T20:08:00Z

Issa: Created page with "Similarly to how a programming language should strive to incorporate all useful features into itself, instead of making the user meta-program their way into a usable language,..."

Similarly to how a programming language should strive to incorporate all useful features into itself, instead of making the user meta-program their way into a usable language, a PDF reader or any application should strive to just simply internalize all the useful features, instead of forcing users to script on features in predictably hacky ways. But how do you know which features are useful to incorporate?

A designer of the program somehow "magically, creatively" comes up with a list of features to include in the program. Maybe they have experience with an existing program of the same type (e.g. if they are designing a new text editor, they probably have experience using an existing text editor), so they know what they are looking to add to their own program. But that only raises the question, how did the designer of the original program of that type come up with a list of features? And if you are designing a program, you probably are looking to include some ''new'' features that do not exist in any program. So how do you come up with those?

I won't answer that general "What is creativity?" question here. But I want to make the observation that this sort of thing probably, most of the time, happens ''incrementally'', so that at any given moment, a given designer only comes up with one new feature, one thing to tweak, one aspect to change. (Of course, by the time a new piece of software ships, it might have many such features included within it, so that from the public's point of view, it might seem revolutionary. I am here only talking about what the creative process looks like internally.)

If we take this incremental view of creativity seriously, it becomes obvious that no single person has "all the answers" to design.

[not quite sure how to connect the above to the below...]

I've come to view plugins as one way of making the search process for features more parallelized. Instead of the designer of the program having to come up with and implement all features, users of the program can script things onto the program. Seeing which plugins are popular among users provides evidence for which features are actually useful.

It's hard to develop things into the main application, and because it's hard to experiment with trying out different features, plugins are the main way in which you can run experiments out in the wild, to figure out what users want/what's popular, and then the main application can take the results of such experiments and implement the best ones. In other words, plugin make it easier to search the space of all possible improvements to make to the main application. So I mainly see plugins as this somewhat expensive way to get data on what works.

People who praise the Helix editor for internalizing things like LSP, treesitter, etc., (but Helix doesn't have a plugin system) are sort of missing the point here; like, yes, it would be better for the editor to come bundled with all the nice features that users might want, but the only reason Helix is even able to do this in the first place is that there was things like Vim and VS Code and so forth that had a plugin system that allowed for these things to come into existence to be played around with. Without that ability to easily search for what is useful, something like Helix just couldn't even exist.

[[Category:Design]]

Different types of file opening tasks

2025-12-06T19:46:57Z

Issa:

# I have a specific path/file I want to open, and I know exactly where it is. Here, I just want to type it out, possibly with some minimal tab-completions so I don't have to type out the whole path. It's also fine if there are some other kinds of "help" the computer provides, like highlighting in red the part of the path that doesn't exist. But importantly, I ''don't'' want stuff like fuzzy search or for the program to recursively search my whole filesystem or other annoying things like this. This is why fzf feels so bad to use for me (for file searching; I love it for shell history search), because a lot of the time I ''know'' where the thing is, but fzf wants to search my whole hard drive looking in places that I don't care about, and then it often doesn't even find the file I want because other "matches" have filled the results list. Emacs's ido-mode is a good example of a pretty good UI for this. File Pilot also has a "filter" search mode that does a pretty good job of this.
# I have already opened the thing before, or the file is nearby to my current file, or I've added my "library" or whatever to tell the program where to find files, and then I want to just search ''by the filename'', very quickly. This is what stuff like fzf, Neovim's telescope plugin, SumatraPDF's Ctrl-k, are coming from. You know you only need to search a small space, a very limited region, so you want fuzzy find, you want things to just automagically show up as you're typing. But importantly, this only works well if you're searching a small space! If you're searching your whole hard drive, it doesn't work well. Vim natively doesn't have this, which I think is why the plugins like telescope and whatever focus on this use-case, even though in my opinion it's not the most important one.
# You only roughly know where the file is, or maybe not at all, or maybe you aren't even sure if the file exists on your system, so you just want to recursively search from some starting "root" location, and it's ok if the search takes a little longer, because you're not doing it on every keystroke, you're just firing off this search process as a widely cast net to see what comes up. This is Vim's <code>:e **/*</code> and <code>:find</code> command with <code>path+=**</code> and stuff is all about. Gnome's file search thing works pretty well, I think. But it can only do this kind of recursive search. fzf doesn't work well for this use-case either, even though I think it's trying to, because it does fuzzy search by default, whereas for this use-case you probably want case-insensitive substring match by default. Also stuff like Google search is kind of in this use-case as well, even though there you're not searching for a ''file'', rather some websites (but a URL is kind of like a file anyway).

And I want to be able to have my program just ... seamlessly be able to transition or somehow magically guess which one the user wants? Or at least be able to have all three through separate keybindings. Most programs can only do one or two of these things, so when I want to do the third thing it feels frustrating.

[[Category:Design]]

Different types of file opening tasks

2025-12-06T19:45:54Z

Issa: Created page with " # I have a specific path/file I want to open, and I know exactly where it is. Here, I just want to type it out, possibly with some minimal tab-completions so I don't have t..."

Category:Design

2025-12-06T19:37:03Z

Issa: Created page with "Pages about design, mostly design of software."

Pages about design, mostly design of software.

Design philosophies of Vim vs Emacs

2025-12-06T19:36:32Z

Issa:

==Modal vs chording==

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

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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 (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==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Indenting: The way TAB indenting works in Emacs is very distinctive. You press TAB and Emacs just indents the line to whatever it thinks is the right level. Vim's TAB in insert mode just inserts a literal tab or spaces depending on the 'expandtab' option. But Vim also gives you, in insert mode, Ctrl-f to do the Emacs-like thing, Ctrl-t to indent the current line, Ctrl-d to decrease the indent of the current line. And many more commands in normal mode.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No line numbers, sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

Both Vim and Emacs have prominent comment colors in their syntax highlighting by default (in Vim it's blue, in Emacs it's red), which I think says a lot. By making most things invisible but making comments stand out, it tells the user that comments are something worth paying attention to. They both come from a saner culture in which programmers were intelligent and comments meant something. Now modern editors have all this crap in your face, and not just that, they make comments ''grayed out'' so that they almost fade into the background (VS Code is the one exception, where its default colorscheme has green comments).

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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

Design philosophies of Vim vs Emacs

2025-12-04T21:29:40Z

Issa: /* Modal vs chording */

==Modal vs chording==

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

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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 (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==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Indenting: The way TAB indenting works in Emacs is very distinctive. You press TAB and Emacs just indents the line to whatever it thinks is the right level. Vim's TAB in insert mode just inserts a literal tab or spaces depending on the 'expandtab' option. But Vim also gives you, in insert mode, Ctrl-f to do the Emacs-like thing, Ctrl-t to indent the current line, Ctrl-d to decrease the indent of the current line. And many more commands in normal mode.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No line numbers, sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

Both Vim and Emacs have prominent comment colors in their syntax highlighting by default (in Vim it's blue, in Emacs it's red), which I think says a lot. By making most things invisible but making comments stand out, it tells the user that comments are something worth paying attention to. They both come from a saner culture in which programmers were intelligent and comments meant something. Now modern editors have all this crap in your face, and not just that, they make comments ''grayed out'' so that they almost fade into the background (VS Code is the one exception, where its default colorscheme has green comments).

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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.

Design philosophies of Vim vs Emacs

2025-12-04T21:22:05Z

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

==Modal vs chording==

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

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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 (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==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Indenting: The way TAB indenting works in Emacs is very distinctive. You press TAB and Emacs just indents the line to whatever it thinks is the right level. Vim's TAB in insert mode just inserts a literal tab or spaces depending on the 'expandtab' option. But Vim also gives you, in insert mode, Ctrl-f to do the Emacs-like thing, Ctrl-t to indent the current line, Ctrl-d to decrease the indent of the current line. And many more commands in normal mode.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No line numbers, sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

Both Vim and Emacs have prominent comment colors in their syntax highlighting by default (in Vim it's blue, in Emacs it's red), which I think says a lot. By making most things invisible but making comments stand out, it tells the user that comments are something worth paying attention to. They both come from a saner culture in which programmers were intelligent and comments meant something. Now modern editors have all this crap in your face, and not just that, they make comments ''grayed out'' so that they almost fade into the background (VS Code is the one exception, where its default colorscheme has green comments).

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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.

Design philosophies of Vim vs Emacs

2025-12-04T21:21:05Z

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

==Modal vs chording==

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

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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.

==Actions: commands vs keybindings==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Indenting: The way TAB indenting works in Emacs is very distinctive. You press TAB and Emacs just indents the line to whatever it thinks is the right level. Vim's TAB in insert mode just inserts a literal tab or spaces depending on the 'expandtab' option. But Vim also gives you, in insert mode, Ctrl-f to do the Emacs-like thing, Ctrl-t to indent the current line, Ctrl-d to decrease the indent of the current line. And many more commands in normal mode.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No line numbers, sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

Both Vim and Emacs have prominent comment colors in their syntax highlighting by default (in Vim it's blue, in Emacs it's red), which I think says a lot. By making most things invisible but making comments stand out, it tells the user that comments are something worth paying attention to. They both come from a saner culture in which programmers were intelligent and comments meant something. Now modern editors have all this crap in your face, and not just that, they make comments ''grayed out'' so that they almost fade into the background (VS Code is the one exception, where its default colorscheme has green comments).

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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.

Design philosophies of Vim vs Emacs

2025-12-01T23:28:49Z

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

==Modal vs chording==

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

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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.

==Actions: commands vs keybindings==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Indenting: The way TAB indenting works in Emacs is very distinctive. You press TAB and Emacs just indents the line to whatever it thinks is the right level. Vim's TAB in insert mode just inserts a literal tab or spaces depending on the 'expandtab' option. But Vim also gives you, in insert mode, Ctrl-f to do the Emacs-like thing, Ctrl-t to indent the current line, Ctrl-d to decrease the indent of the current line. And many more commands in normal mode.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No line numbers, sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

Both Vim and Emacs have prominent comment colors in their syntax highlighting by default (in Vim it's blue, in Emacs it's red), which I think says a lot. By making most things invisible but making comments stand out, it tells the user that comments are something worth paying attention to. They both come from a saner culture in which programmers were intelligent and comments meant something. Now modern editors have all this crap in your face, and not just that, they make comments ''grayed out'' so that they almost fade into the background (VS Code is the one exception, where its default colorscheme has green comments).

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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.

Design philosophies of Vim vs Emacs

2025-12-01T23:24:54Z

Issa: /* Visual noise */

==Modal vs chording==

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

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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.

==Actions: commands vs keybindings==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No line numbers, sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

Both Vim and Emacs have prominent comment colors in their syntax highlighting by default (in Vim it's blue, in Emacs it's red), which I think says a lot. By making most things invisible but making comments stand out, it tells the user that comments are something worth paying attention to. They both come from a saner culture in which programmers were intelligent and comments meant something. Now modern editors have all this crap in your face, and not just that, they make comments ''grayed out'' so that they almost fade into the background (VS Code is the one exception, where its default colorscheme has green comments).

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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.

Design philosophies of Vim vs Emacs

2025-12-01T23:20:04Z

Issa: /* Visual noise */

==Modal vs chording==

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

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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.

==Actions: commands vs keybindings==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No line numbers, sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

Both Vim and Emacs have prominent comment colors in their syntax highlighting by default (in Vim it's blue, in Emacs it's red), which I think says a lot. By making most things invisible but making comments stand out, it tells the user that comments are something worth paying attention to. They both come from a saner culture in which programmers were intelligent and comments meant something. Now modern editors have all this crap in your face, and not just that, they make comments ''grayed out'' so that they almost fade into the background.

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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.

Design philosophies of Vim vs Emacs

2025-12-01T23:16:24Z

Issa: /* Visual noise */

==Modal vs chording==

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

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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.

==Actions: commands vs keybindings==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No line numbers, sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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.

Design philosophies of Vim vs Emacs

2025-12-01T23:14:51Z

Issa: /* Visual noise */

==Modal vs chording==

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

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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.

==Actions: commands vs keybindings==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no git blame next to every line as the cursor moves, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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.

Design philosophies of Vim vs Emacs

2025-12-01T23:13:02Z

Issa:

==Modal vs chording==

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

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, the expectation is that you will have a single Emacs instance open. Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

See [https://nullprogram.com/blog/2017/08/22/ this blog post] for more details.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise. This is even reflected in the motion to move up or down a line: by default, j and k move down or up by logical lines instead of screen lines. However, due to this lineage, Vim does not deal well with long lines of text. Recent version of Vim have :set smoothscroll, but this only partially works.

Emacs is like most other text editors in that it has no concept of linewise. Ctrl-n and Ctrl-p move by screen-lines, not logical lines, which makes sense when you think of the buffer of text as a stream of characters rather than an array of lines.

==Mappings: keystroke based vs function-based==

In Vim, commands like "copy text" don't have a "name"; they are simply the keystroke that is used to perform that action. So if you want to "program" Vim to repeat some action, such as when defining a mapping, you simply tell Vim which keystrokes you want to repeat.

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.

==Actions: commands vs keybindings==

Vim often uses the command-line for even common actions, e.g. :w to save a file [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/]. Emacs relies more on keybindings, e.g. Ctrl-x Ctrl-s to save a file.

But there are some exceptions. To open the file that the cursor is on, Vim has various keybindings, including <code>gf</code>, <code>gF</code>, Ctrl-w f, etc., but Emacs only has M-x ffap.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: consistent vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a very consistent word movement, which means you will never have to backtrack.

Emacs does the thing that most other text editors do, which is that if the cursor is before/on a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols. Emacs caters to the most common thing, and sometimes you need to backtrack.

Suppose you have some text like: <code>Hello, world.</code> and the cursor is past the final period. You want to add the word <code>there</code> before the comma, to make it <code>Hello there, world.</code> In Vim, you press b a few times to move backwards by word, until the cursor is on the comma, at which point you can go into insert mode to type the "there". In Emacs, Alt-b will move the cursor back by word, but once the cursor is on the 'w', pressing Alt-b again will jump past the comma onto the 'H' -- in other words, it overshoots. So then you need to backtrack by pressing Alt-f to move forward by word.

==Scrolling: scrolloff vs scroll-into-view==

In Vim, defaults.vim sets scrolloff=5, which means that when the cursor is at the edge of the window, it will always show 5 lines of context. You can never "touch" the very edge of the screen, because the screen will scroll when you try to move to the edge. (But due to Vim's line-oriented heritage, this will scroll into view an entire logical line instead of just one visual line.)

In Emacs, the default behavior is instead to jerk the screen to the center ''after'' you step off the edge.

==Search and replace==

Emacs automatically does all the case variants, e.g. if you search and replace foo → bar, it also does Foo → Bar, FOO → Bar, etc. Vim doesn't do this.

==Visual noise==

Emacs has more visual noise, e.g. the line continuation markers, incremental search by default, highlighting of all search matches as you type, a status bar. Vim comes from an environment where terminals were very slow so it tries by default to not draw to the screen very much. This means fewer things flash on the screen as you do things -- quite monastic vibes.

Of course, by modern standards of things like VS Code, Zed, JetBrains, etc., even Emacs will feel minimal! No sidebar with a file tree, no minimap that shows a zoomed out view of the file, no tabs shown by default, no git gutter, no popups nagging you about updates or extensions to install, no breadcrumbs (path of nested scope at the top), no hover-over documentation.

==Prompting the user==

For Vim, see [https://www.reddit.com/r/vim/comments/267vrv/i_am_tim_pope_crafter_of_plugins_ama/chojzsb/].

Emacs often prompts the user.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Both have a way to look things up based on keystroke or command name though. Vim has a universal :help command, while Emacs has e.g. Ctrl-h k for keystrokes or Ctrl-h f for functions.

==Selection endpoint==

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.

Design philosophies of Vim vs Emacs

2025-12-01T23:04:34Z

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

Design philosophies of Vim vs Emacs

2025-12-01T23:02:15Z

Issa: /* Session management: per project vs single instance */

Design philosophies of Vim vs Emacs

2025-12-01T22:59:06Z

Issa: /* Scrolling: scrolloff vs scroll-into-view */

Design philosophies of Vim vs Emacs

2025-12-01T22:55:07Z

Issa: /* Modal vs chording */

Design philosophies of Vim vs Emacs

2025-11-27T21:35:06Z

Issa: /* Line-based vs character-based */

Design philosophies of Vim vs Emacs

2025-11-27T21:08:16Z

Issa: /* Word movement: predictable vs "do the common thing" */

Design philosophies of Vim vs Emacs

2025-11-27T21:00:44Z

Issa:

Design philosophies of Vim vs Emacs

2025-11-27T20:59:31Z

Issa: /* Documentation: graph/linear vs tree */

Design philosophies of Vim vs Emacs

2025-11-27T20:57:07Z

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

Design philosophies of Vim vs Emacs

2025-11-27T20:55:08Z

Issa: /* Line-based vs character-based */

Design philosophies of Vim vs Emacs

2025-11-27T20:53:14Z

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

Design philosophies of Vim vs Emacs

2025-11-27T20:48:28Z

Issa:

Design philosophies of Vim vs Emacs

2025-11-27T20:47:42Z

Issa: /* Actions: commands vs keybindings */

Design philosophies of Vim vs Emacs

2025-11-27T20:46:32Z

Issa:

Design philosophies of Vim vs Emacs

2025-11-27T20:42:29Z

Issa: Issa moved page Vim vs Emacs to Design philosophies of Vim vs Emacs

Vim vs Emacs

2025-11-27T20:42:29Z

Issa: Issa moved page Vim vs Emacs to Design philosophies of Vim vs Emacs

#REDIRECT [[Design philosophies of Vim vs Emacs]]

Design philosophies of Vim vs Emacs

2025-11-27T20:40:55Z

Issa: /* Search and replace */

Design philosophies of Vim vs Emacs

2025-11-27T20:40:33Z

Issa:

Design philosophies of Vim vs Emacs

2025-11-27T20:29:11Z

Issa:

Design philosophies of Vim vs Emacs

2025-11-27T20:26:08Z

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

Design philosophies of Vim vs Emacs

2025-11-27T20:24:07Z

Issa:

Design philosophies of Vim vs Emacs

2025-11-27T20:21:21Z

Issa:

Design philosophies of Vim vs Emacs

2025-11-27T20:16:36Z

Issa: /* Session management: per project vs single instance */

Design philosophies of Vim vs Emacs

2025-11-27T20:15:31Z

Issa:

Design philosophies of Vim vs Emacs

2025-11-27T20:13:34Z

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

==Modal vs chording==

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise.

Emacs is like most other text editors in that it has no concept of linewise.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: predictable vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a pretty predictable word movement. Emacs does the thing that most other text editors do, which is that if the cursor is before a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols.

Suppose you have something like: <code>"hello"</code> where the cursor is on the first quote. In Vim, w will move the cursor onto the h. In Emacs, Alt-f will move the cursor past the h onto the second quote.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.

Design philosophies of Vim vs Emacs

2025-11-27T20:08:43Z

Issa:

==Modal vs chording==

==Unix as IDE vs Emacs as OS==

Vim tries to just be a text editor, and tries to play nice with the other tools on your computer, using commands like <code>:!command</code> (runs external command) or <code>:w !command</code> (pipes text to external command via stdin) or <code>:r !command</code> (reads from external command via stdout).

===...with some exceptions===

Vim has a built-in spellchecker, whereas Emacs doesn't (it does come with flyspell, which works with an external spellchecker like hunspell or aspell). (Emacs comes with tetris, an RPN calculator, an email client, etc., but not a spell-checker!)

==Session management: per project vs single instance==

The "right way" to use Vim is to have one instance of Vim open per "project". Each Vim instance maintains its own current directory, so you can e.g. open files relative to that current directory.

In Emacs, Emacs itself doesn't maintain its current directory, and instead all file-open actions are relative to the buffer's directory.

Vim can do the Emacs thing with :set autochdir, but this is disabled by default.

==Line-based vs character-based==

Vim comes from a lineage of line-based editors. Registers can be linewise or characterwise, which means that actions like pasting text can act on entire lines or on characters. Some commands, like :substitute or :global, only work linewise.

Emacs is like most other text editors in that it has no concept of linewise.

==Tree-based undo vs stack-based undo==

==Multiple similar commands vs single repeated command==

This one is a bit hard to explain, but there is a definite pattern where Vim prefers to give the user multiple similar commands, while Emacs prefers to give a single command that you can then repeat or use creatively. The best way to explain is to give a bunch of examples:

* Changing the screen view relative to cursor: Vim gives you zz to scroll so as to leave the cursor at the center of the screen, zt to scroll and put the cursor at the top, and zb to scroll and put the cursor at the bottom. Emacs just gives you a single command, Ctrl-l, which when repeatedly pressed, will cycle between all three views.
* Moving cursor to top, middle, bottom: Vim gives you H to move cursor to the top of the screen, M to move to middle, and L to move to bottom. Emacs just gives you Alt-r, which will cycle between the three configurations.
* Folding: Vim gives you fine-grained commands like zo to open a fold, zc to close a fold, zR to globally reduce the fold level in the file, etc. Emacs as far as I know doesn't have folding by default, but certain major modes like org-mode and markdown-mode do have folding, and in these, you simply press TAB to cycle the different folding levels, or Shift-TAB to do the cycling globally across the entire file.
* Vim gives you Y, D, C, to copy, delete, and change (respectively) until the end of the line. Emacs just gives you Ctrl-k, which it then expects you to creatively make use of (e.g. if you want to copy until the end of the line, you do Ctrl-k to delete until the end of the line, then Ctrl-/ to undo).
* Vim has / to search forward, ? to search backward, then n or N to repeat that search in the same direction or opposite direction. Emacs just has Ctrl-s and Ctrl-r to do the search forward or backward. If you want to repeat the search, you just keep pressing Ctrl-s.
* When you have multiple split windows, Vim has Ctrl-w followed by h, j, k, or l to move to that window. It also has Ctrl-w followed by w to keep cycling between the splits. It also has Ctrl-w followed by p to toggle between the two most recent splits. There are just a lot of fine-grained choices you can make. Emacs just gives you Ctrl-x o which cycles.
* 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.

==Word movement: predictable vs "do the common thing"==

Vim's word-based motions like w, b, and e always treat contiguous alphanumeric sequences as single words, and also treats contiguous symbols as single words. This leads to a pretty predictable word movement. Emacs does the thing that most other text editors do, which is that if the cursor is before a symbol, then moving forward by one word will not just jump to the end of the symbols, but will jump to the end of the alphanumeric sequence ''after'' the symbols.

Suppose you have something like: <code>"hello"</code> where the cursor is on the first quote. In Vim, w will move the cursor onto the h. In Emacs, Alt-f will move the cursor past the h onto the second quote.

==Documentation: graph/linear vs tree==

Vim uses a wiki-like help system, where you can click on links to read the sections. It also contains a linear book under :help user-manual. Emacs has a GNU-like hierarchical tree documentation system.