Vim Modes Transition Diagram | Hacker News Reader

Vim Modes Transition Diagram

rawgit.com

I appreciate the effort that went into this, but I think it actually makes learning vim appear more complicated than it is.

The approach to vi(m) that really worked for me is to regard the different modes (especially insert mode) as commands rather than "modes". Entering text is a single command, usually starting with 'i' or 'a', terminated with <esc>. For each command you learn, get in the habbit to initiate and to terminate it, just like in primary school you learned the habbit of finishing your sentences with a punctuation mark. Then you don't "get stuck" in different modes anymore.

I suppose this is useful for implementing Vim-like functionality, not as an usage manual.

Fair point, though I'd argue that's not its function.

Documentation is a technology, and all technology serves a goal-oriented process.[1]

What you're looking for is a Quick Start Guide. These exist. Vimtutor would be an excellent example.

This ... is a map of the landscape. It doesn't tell you where to go, or what the highlights are. But if you happen to be in one part of the landscape, or want to know what's in some remote part, this shows you both what's where and how to get there. And links to a detailed description for closer inspection.

And in that process and to that goal, it really is quite good.

________________________________

Notes:

1. That is a bald statement proposed as but not presumed true. Change my mind!

That’s what I always assumed this was. You’d be nuts to show this to a beginner.

Pretty much.

Or you'd want to show it to a beginner as a phased reveal. That might actually make an interesting evolution of the diagram, which I'm visualising in my mind as either a set of concentric circles or regions of expanding complexity, or a set of 3D-relief "peaks" emerging from a "feature sea", where the basic elements (say, the Insert mode entry points, h/j/k/l keyboard movements, and, um, how to quit, might be covered.

With more advanced functionality exposed as deeper / more remote regions of the map.

If you've not realised this yet, the diagram is clickable, and links through to the Vim manual section corresponding to the feature in question.

This is quite excelently done, thank you darcyparker!

Note that this doesn't include all features. Digraphs (Ctrl-K from Insert mode) are missing, e.g.

yes, it's great!

It doesn't have alt<char> to enter normal commands from insert mode (double the number of lines).

It doesn't have (Vim 8) terminal mode.

Alt+char in terminal Vim is just another way of typing Esc+char.

rawgit.com is sunsetted[1], so this URL may die any day now. It's simply a proxy server for content hosted on GitHub. In this case, the real source is https://gist.github.com/darcyparker/1886716, and it's displayable (officially) at [2].

[1]: https://rawgit.com/ [2]: https://gist.githubusercontent.com/darcyparker/1886716/raw/c...

Does anyone actually use select mode?

yes, it's useful to comment out a bunch of lines.

I’m pretty sure you’re talking about visual mode, not select mode.

Yes.

I use normal select when:

- I want to apply a regex to a specific area, e.g. a single function (vjjjjj:s/my_function/my_new_function/g<enter>)

- I want to cut some text and I don't want to count how many words out it is (vwwwwx)

I use block select when:

- I want to delete a section of fixed width formatted text (Vjjjlllx). Useful for manipulating logs with a fixed width prefix.

- I want to append text to the start of a line. (VjjjjjjI# <esc>). Useful for commenting out lines.

You're actually talking about visual and visual block (although V is visual line and <C-V> is visual block in your examples). Select is a weird mode where typing will overwrite your selection, similar to how it works in a modeless editor like notepad or the HTML textarea.

Huh, TIL. I'm amazed I've been using Vim for this long and there are entire modes I didn't know.

You're talking about visual mode, select mode is entered by pressing gh in normal mode.

Select mode is actually exactly what I was looking for a few days ago. I had a visual block selected and wanted to replace it, but all I know how to do was delete, reselect, and add.

I usually hit “c” in visual block mode, and re-type. How does select mode work by comparison?

In select mode, you just start typing as if you had already pressed c. It works similar to text selections in Windows.

But to get to Select mode in the first place, you need a key sequence that seems longer than the direct route:

- select from block requires Ctrl-G and then start typing, but c or s is more direct

- select character uses gh, but c is more direct

- select line uses gH, but C is more direct

In what circumstances would Select mode be more direct than to go from Visual to Insert, or from Normal to Insert?

In Windows builds of Vim, mouse selections default to Select mode rather than Visual mode. I think that's probably the only reason it was added, and I doubt anyone enters Select mode "manually".

If I recall correctly, it’s more or less enabled by default in gVim on Windows for mouse selection (see ':behave'). I’ve never seen anyone deliberately invoke it, and I’ve definitely seen people avoid that behaviour on Windows.

I would definitely consider it a misfeature, given how it complicates things, muddying modes when invoked, and when a simple c or s from any visual mode has roughly the same effect.

I use it every once in a while to truncate aligned text in tables. It's not very useful, but I'm glad it's there.

The big question for me is whether anyone knew of virtual select mode, enabled by `gR`.

It's like select mode except that it replaces screen state instead of characters, so pressing `<Tab>` will replace `tabstop` characters instead of just one.

This looks super handy as a reference. I love a nice organized diagram when I'm sort of ok enough at something already.

I just wish I had a big enough screen to read this all without zooming out

I've been using a TV as screen for increased real estate and I must say I'm happy

Wow this is really cool! A lot of commands are just muscle memory at this point, but seeing things visualized like this is really neat.

Ah, finally a map to escape this dreadful labyrinth

  <ESC><ESC>:q!

There you go.

:q twice, when vim is recording.

I never learned Vim commands (*) because I couldn't get past how different it is to use compared to everything else. I found the selection of editor modes confusing because I'm used to just typing where the cursor is. This is the first diagram/cheat sheet which has made some sense of what's going on.

Thanks for posting this; bookmarked.

(*) apart from :q!

The most useful command, in my experience, is ‘:s’—it alone justified the use of Vim for me. I occasionally drop some lines in Vim, use ‘:s’ and paste the result into the terminal—simply because it's much easier to edit multiple shell commands this way than to figure out how to do it with sed or whatnot.

It omits shift-cursor inputs, however it seems to finally answer for me the mystery of what those weird modes are that are entered by shift-selection: ‘select visual’ and ‘insert select’, if I'm not mistaken. Also apparently I forgot about ctrl-g, though it likely has a different meaning in Emacs' Evil.

Vim is weird. It is the pure opposite of user friendly design, and yet it has a huge userbase.

I don't think it's the "pure" opposite. Notably, it's extremely stable and even all of the quirks which aren't fixed for reasons of compatibility are documented in its built-in help.

I think almost all modern products focus exclusively on growth: acquiring new users. That means that it's OK to break existing behaviors if it makes something easier for a newcomer. Vim does not have this attitude, so a newcomer has a steep learning curve, but an old-timer doesn't have to worry about his platform changing from under him.

It's the opposite of new-user friendly design.

For some of us, it isn't that hard to learn, and gives us an entirely new way to think and interact with a computer.

I think there is a powerful lesson for user-facing application developers here. Sometimes you're better off thinking of power users and enticing newcomers to put in the effort. Blender seems to follow that approach as well.

I started using vim quite recently and I have a pure opposite view point as yours. With vim, I find myself editing code effortlessly, without conscious effort. This never happened when I was doing this with other text editors using keyboard shortcuts or the mouse.

How did you get started?

I was using vim mostly while working on projects with a single board computer. But at that time I only knew the basics of searching, jumping to a line and entering insert mode to edit some text.

Recently I installed vim plugin for vscode and spent a little time digging deeper into vim and practiced until it got into muscle memory.

One little shortcut that I've noticed even some experienced users aren't aware of is :x to save and exit. It is equivalent to :wq

Sounds like you're using it wrong. I love that I don't have to touch my mouse and can do everything a that an IDE can do.

Also very importantly, it doesn't report everything you do under the telemetry umbrella like all Microsoft products do.

Or cripple projects that remove that telemetry (see Vscodium which cannot use remote extensions and the new default LSP named Pylance, because Microsoft forbids it).

Edit: vscode also has some proprietary debuggers.

https://github.com/VSCodium/vscodium/blob/master/DOCS.md#pro...

Many advanced tools aren't "user friendly" when you only apply that to how quickly you can understand them. Vim has a steep ramp for usability and power, but the payoff is that it decreases in steepness after a while and (this is important) continues for quite a while. It doesn't do that by slowly doling out the standard set of features over a long period, but by giving you many advanced things you can do which end up greatly increasing productivity.

First you learn how to enter text and move around a bit.

Next you learn some more advanced features to move and edit more effectively.

Then you learn that vim actually functions at different levels, characters, words, lines, and paragraphs, and learn ways to work on those items specifically.

You learn that complex macros are built in and can easily be recorded and applied as needed.

Finally (maybe?) you learn that all this combines into its own little programming language made to work on documents, and you can use this to quickly do amazing things.

But here's the thing, even if you stop only partway into it, you've still learned how to edit files in an editor that will be on every Unix machine you encounter, even if that version may not have all the bells and whistles.

It's an extremely powerful and ubiquitous tool. Even if you don't use it as a primary editor, there are benefits to knowing how to use it with a moderate proficiency, so many people do.

> learned how to edit files in an editor that will be on every Unix machine you encounter

And this is instant cred when one is new to a project, and have to log in and fix something on a random serber out in the cloud.

Vi is something of a litmus test.

I've watched people do work in vim. They don't work any faster than people using VS Code. Quite the opposite. I see them make more mistakes and lose their place often because they don't have the same quality of tools integrated. By the time they've navigated manually to whatever code symbol they want to edit, I've already gotten my edit done and moved back to the function I came from.

The same people using vim swear by using CLI only tools and by the time they've found the command they want to edit and run in their bash history, I've hit Ctrl+Shift+G, entered my commit message and hit Ctrl+Enter to push. In the time it takes them to switch modes, I've already run the command I wanted to run since many commands are a single hot key and others are on an MRU list.

For editing stuff on a live server, in those rare events when nano isn't available I've always gotten by knowing the bare minimum - how to insert text, write and quit. But I haven't encountered a server lacking nano in years.

Maybe I haven't seen the fastest vim user though. So I looked just now and found [0]. I chose to watch [1] and ~1:24 you can see a demonstration of the guy typing out a command, "Switch" to switch a code symbol from the "true" to "false"... I thought that was hilarious because he typed 6 characters (7 if you include ENTER) in order to save himself from typing 5 characters and I just couldn't watch anymore after that so I left, wondering how many man hours have been spent bike shedding in vim.

That said - I didn't have the patience to find anything showing somebody doing something in vim that can't be done faster in VS Code, Sublime, etc. - so maybe a vim fan can point me in the right direction?

[0] https://old.reddit.com/r/vim/comments/3k1b7n/fastest_vim_vid...

[1] https://www.youtube.com/watch?v=zIOOLZJb87U

I think you didn't quite understand what you were seeing in that video. That's a person showing off a quick plugin/function they made for vim that when called can switch things defined from one state to the opposite state. The top half of their screen is the source to what they wrote (I think, on mobile).

They are showing how it works, so as an example highlight/select manually a bit of text then manually run it to show it swapping the value. There's a few things to consider here:

- They are typing it out because the are demoing it and that's the name it's defined as in the code. Normally someone adding it would also add a key combo activation for it if they planned on using it often in that manner, and make it work on the word element under the cursor.

- Even if a key combo wasn't added, they could also use this while selecting a larger chunk of text to switch all occurrences of one thing the the opposite.

- The real usefulness for this is more likely in the case of some well formatted JSON, where you could start a macros, search for the next top level object, they search for a specific key in that object you know is the next occurr nice of a search term, then go to nth item, then run switch (maybe even typing it out). Then stop the macro. You can then rerun that macro with 1 (or at most a few) key presses the number of times you want, to perform those complex actions a defined number of times.

As needed, vim is like an extensible interactive sed command. That doesn't mean I never use vim, but being able to do something similar to the text manipulations I do with sed while withing the file to confirm it worked right and undo if needed is sometimes useful.

Could the JSON example above have been done with a dedicated tool? Sure. But it gets more complex for dedicated tools if the JSON is embedded in something else, and the important idea is not JSON editing, but that vim gives you a toolset that works just as well for XML or source or plain text, as the primitives it works with generally map well to how we use text.

Thanks for the explanation! I'll try to watch a few more videos.

ergonomics, intuitivness, functionality are the three sides of software development.

If you favor one corner, the opposit side will degrade.

VIM is full on functionality/ergonomics with absolutely zero intruitivness.

It's a very steep learning curve.

Once you reach that point in the curve where stuff are easier/faster to do in vim then something else, you can never go back.

ergo the user base.

The basic vi assumption is: "We spend more time editing text than authoring it, and therefore the keyboard itself is the UX."

This is loke starting a maze at the end, amd precisely the sort of backward thinking that affords some excellent solutions.

This isn't to scoff at great UX and design work; merely to point out that the wildly offbeat can surprise in a good way.

Thirty-five years ago, I had a couple of slightly frustrating weeks sitting in front of a VT-200 serial terminal.

Over the subsequent three and a half decades, I've had an editor on virtually every computer system worthy of the name which Just Does What I Want It To. It's there for everything from one-liners to book-length files to editing multi-GB datasets or Web scrapings.

And I'm still learning features and concepts, though now around vim rather than the original BSD vi.

And no, vi isn't the only editor I've used with proficiency: DOS EDIT, EDLIN, KEDIT, WordPerfect 4.11, VMS EDT, VMS EVE, TSO/ISPF, Emacs, pico, nano, and more.

I quite honestly wish I could get back into emacs, but vim has a stronger pull and solves virtually all my problems. org-mode does have strong appeal, however.

Love org-mode. You should look into Spacemacs or Doom Emacs, with their focus on vim-style keybindings. I’m still learning my way around Emacs so appreciate Spacemacs for its discoverability. Doom is supposed to be quicker and more stable though, so it sounds like that might be the distro for you.

Vim is very user friendly - to power users.

Yes, it takes a bit to get used to its controls, but I'm not sure there's a super easy way to teach modal editing to newcomers. On the other hand it's a really reliable and efficient tool that just doesn't try weird stuff. If you have a 1000 line configuration file you can blindly upgrade to the next version and trust everything is still working exactly the same. Considering how many apps do the opposite and add random changes all the time to A/B test everything, this is very valuable.

And while I wouldn't call it perfect, I think editing text is really, really intuitive and fast once you're used to it, to a degree using a mouse in other editors feels slow.

The beauty of Vim is that it uses almost a natural-language approach to editing. It's not the opposite of user friendly, it is, in fact, much closer to the user's consciousness, than many other editing paradigms. I.e. when I am editing text in vim I am translating my intentions to vim commands almost directly. "Change this paragraph" becomes "cip", or "cap" as in change inside/around paragraph. Select text up (or down) to line 30 is v30G. This one does not translate to proper English directly, but it's pretty straitforward when you know how to build Vim's "phrases".

A violin is the pure opposite of user-friendly design, and yet, there are millions of people playing it.

Yes, but only a violin can make the violin sound.

I'm a vim user sometimes because of the peer pressure but it's basically a cult and a waste of time if you can avoid it.

The reason vim doesn't use cursor keys for movement is not because of some secret insight but because the keyboard it was invented on didn't have them.

Similarly the concept of modes was just due to the time period. Commands were the normal way to operate editors. For many people, not many years had gone by since the editing was done on a teletype. Interactive editing was barely even a thing.

I recommend the `micro` editor.

The historical reason why home row keys are used for movement instead of cursor keys is irrelevant. Even if the idea was a historical accident, it turned out to be a good idea. Not having to move the position of your hand to move the cursor is comfortable and fast.

The way I finally got vim to stick was by integrating it into my existing development workflow.

I had tried to go all in on vim a few times but the learning curve always made me feel less productive than working in VS Code.

After adding the vim extension in VS code and gradually learning new commands, it stuck.

Very happy to have learned vim but I agree that the learning curve is pretty steep usually. It was frustrating enough that I published an interactive vim course that helps people get over the hurdle.

Vim is like an F-15 fighter jet. You have to study and train to know how to use it, and some elements of its design are historical or just bizarre, but if you know how to use it you are far more capable than you would be with other tools in the same category.

Thanks. Where can I order this as a poster-sized print for my office?

kinkos

The diagraitself is an SVG. You can scale that to any size you like, using an SVG editor (e.g., Inkscape).

Take that file to your local print shop, as suggested in another comment.

I always get trapped in record mode but I don't see that in this diagram. Am I missing something?

q another character begins recording a macro. press q again to finish recording.

Well, it's not a mode. It's recording, but you can freely change between modes while recording and this will be part of the recording. I believe you can even start a recording in one mode and exit it in another, although this has limited use.

It is most certainly a mode, from a usability standpoint. :q no longer works once in record mode; which fits the definition of modality.

q + something else -> starts recording into buffer <something else>

q again -> finish recording

@ <somethinge else> -> replay recording of buffer <something else>

Good summary, but minor addition: `q` is also a valid input. Hitting `qq` starts recording in the `q` buffer, and it stops when the key is pressed a third time in normal mode.

I recently had the happy discovery that q: puts you into the : buffer, which is your command history. You can navigate to a recent comment and just enter to execute. Bonus point for it being the opposite of :q

It's the Q character. That usually happens to me when I mistype a semicolon rather than colon when trying to quit.

Q enters ex mode

q is used to start a recording

That was imprecision on my part. I should have said "Q key" instead -- the capitalization was to make it stand out.

Yeah; With basically everything using q to quit, the inconsistency is infuriating. It would be bad enough if it did nothing, but instead of changes modes that you need to explicitly escape before the real quit works.

The best way to stop doing it accidentally is to start doing it deliberately, then the muscle memory will catch up.

A version for Bostic (n)vi please.

So uneasy to look at this on my vertical monitor 1080x2560, all I see is a giant Insert rectangle and a horizontal scroll. But I appreciate that work anyway because all that areas are clickable and it will not be easy to rearrange that diagram for 1% users with strange looking monitor.

It's a SVG-file, not a website, so just scroll to fit, or blame your browser.

Now that everyone has smartphones vertical screens are no longer an uncommon trick for programmers who've realized that text scrolls more vertically than horizontally - they're the most common aspect ratio.

Does anyone know of a similar diagram to explain emacs?

Reply on news.ycombinator.com