Practical Vim command workflow (2023) | Hacker News Reader

Practical Vim command workflow (2023)

m4xshen.dev

106 pointstosh97 comments

Open articleView on HN

I never managed to move away from arrow keys.

Anyway, start early/stay consistent. This stuff seems overwhelming until you surprise yourself with muscle memory

Can't speak for others, but I don't think about spelling/make-up of words while typing. They flow.

This is the ideal state with vim; muscle memory for documents. In the end it can reduce effort/improve speed

Too late now... but I'd like to edit :)

:%s/vim/any editor/

A similar idea applies to skateboarding, basketball, whatever. Sure - it's physically exhausting to get there, but the motions become routine

using Vim without using h, k, j, and l for navigation is incomprehensible for me. 20% of the keystrokes that I perform in command mode must belong to that group of four keyboard navigation moves.

In fact, I have Vim mode turned on in all contexts where it is possible -- in my terminal, in any editor I use, etc. It is difficult for me to properly edit text without Vim mode, honestly.

But not using h, k, j, and l would cripple my productivity in command mode. It allows me to zip down 6-8 lines just by holding the j key down for an extra split second, or 6-8 lines up with k key -- and I can control exactly which line to stop on by lifting my finger.

It pains me to think of not having this at my fingertips.

I'm slowly getting into it, though I definitely didn't start early (been coding since 2009). Although funnily enough, I do remember using Vim a couple of times back when I was 10 years old, on my 95 Packard Bell.

For me, hjkl for directional keys is extremely difficult to remember. I think because in the spoken word we say "up and down", not "down and up", so my brain wants j to be up and k to be down. My muscle memory really fights me on that.

It surprises me how few people are aware of https://vim-adventures.com

Beat that game and hjkl will feel just as natural as arrow keys, and so will a ton of vim commands.

I think the creator does himself a disservice by selling 6 month licenses rather than lifetime. But 6 months is more than enough to play through it. I think it only took me a couple days.

Agree on the disservice; I'm aware of this and many other gamified ways to learn 'vim'.

I'd be more likely to buy/support lifetime over six months, or really, any interval. This is a largely-unchanging editor. Why drag out this relationship? Once I learn the things, it's on me to put them to practice/make it real. Six months is lifetime, if you haven't mastered it by then I'm not sure you will.

I can't say whether or not this would be more effective than others, I haven't played it.

The proposition of buying a license at all is a bit of a hard sell. Again, there are a lot of free things to give me the info and gamified experience. Perhaps not as nice, but this needs to do a bit more to sell me than look pretty.

The hard part is aided by several other freely available games, yet experience of all kinds still teaches. I have a feeling it's more motivation or personal choice, than game(s), when it comes to why my arrow-key usage persists.

Then again, I also don't use services for languages. I'd rather read. A lot.

I haven’t seen any Vim gamification that is anywhere near the quality of vim-adventures. But if you know of any I’d love to check them out.

This is more well put together than any I recall! I don't say any of this to diss it; were I new, I'd consider it.

Presenting a subscription is just a little off-putting. How deep does the hole go, you know?

The active side of learning is one thing. The game you choose, the manuals you read, or whatever.

The other side - what happens outside of that, both actively and passively (with time), is important too. I want to stress that.

It's easier to build good habits than break bad ones, and the lines between aren't clear.

The learning aid doesn't matter if you aren't dedicated to the teachings by putting them into practice while editing.

In fact, habits you have unrelated to editing can hurt your editing!

I didn't want to turn this into a spat saying "this thing" or "that one". It defeats the purpose of my message: the learning aid doesn't matter so much, dedicating yourself to it does.

Disclaimer: I'm biased. I learned before gamification was so readily available. I can't objectively judge them completely

The game I played was called "painstakingly edit a lot and look at a cheat sheet until the bones remember". Self-enforcing learning model! Both good and bad, again - habits.

To be clear, I'm not intending six months to be some sort of limit. I know it seems elitist but my intent is the exact opposite.

Someone willing to be so dedicated that they'll invest both money and time, while not falling back to old habits, will most likely succeed without the 'payment' part.

Anyone should be able to sit down and dedicate themselves to self-improvement or entertainment for free.

It's all very arbitrary. Not all six months are equal. Not all editing is equal. I edit more than any healthy person should, is it good or bad? Who knows.

+1 to vim-adventures, excellent game and well worth the money if you're a committed power user

I couldn't get used to it either, so I've rebound it so that IJKL is up/left/down/right (like WASD) and H is for insert mode. Yes, it means that vim mode in other programs isn't as immediately intuitive, and ones that don't allow for much rebinding aren't very nice to use, but for me that doesn't matter as much as having something that feels good in the software that I spend almost all of my time in.

Arrow keys suck so much on most laptops, that I do everything to avoid them, I use Vim mode plugins in my browsers. There's even a global Vi mode available for macOS, I'm sure something similar is possible on Windows with autohotkey, not to mention Linux.

They only started sucking in the last decade or so when they stopped making them in the inverted T shape.

Sure, but I can't use an X220 anymore. Man I soooo wish I could have a laptop with the hardware of the Mac and the keyboard of an old ThinkPad (with better aesthetics). Unfortunately, not so many people seem to want this.

Remapping them is always an option (though it obviously has its disadvantages).

I use j & k, never really have used h & l, even then I don't use j & k much since there's better ways to get around. / - search & n/N for next backwards and forwards. w - one word forward b - one word backwards

w one word forward and land at the beginning, while e is one word forward but land at the end.

All posts I read on VIM always compare to a barebone editor without proper refactoring plugins enabled it seems. Would love to see a proper comparison against state of the art refactoring and against a skilled user of those systems.

First one for instance with resharper plugin enabled or in any IntelliJ IDE: Ctrl R R, type new word. Bonus; replaces all instances of the variable and recognizes scope in the file so if you have two locals with the same name over two methods it would change only the one you want. You want all, multi-carrot expansion Ctrl D D until you hit what you want and replace. Multi Carret is so powerful, find a repeating pattern, can be anything and even if it occurs further down where you don’t want to change just stop hitting expansion. Sure, you can do the same with VIM but comparing VIM to modern refactoring plugins is way more fair.

Things like extract method, extract variable and replace all instances at once are also one keybind away.

I didn't get the impression that this post was trying to compare vim to anything (which is refreshing). Seems like this is simply demonstrating how to use vim, given a few real-world editing examples.

You can of course get plenty of "refactor" plugins for vim out there but I've never found a need for one. Even in more complex codebases with multiple instances of a local variable like you mention, I tend to do more "find-and-replace in selection": V to Visually select a block, then just :s/foo/bar/g

Generally with you

That said, many of these refactor systems are multi-file capable. Or even more fancy, they understand for example that an export is being renamed & update all consumers, leaving all other uses of that variable name as-is.

I'm a pretty mediocre but long time vim user. I don't intend to leave. But I remain interested in codemod tools that can help me reshape code at scale.

You do use LSP don't you? There's refactoring tools there, I really fail to see how Neo/Vim is lacking in this regard. Sure, it requires some deeper understanding and setup, but that is the Vim way. For people that do not want to deal with this there's IntelliJ or VSCode.

> All posts I read on VIM always compare to a barebone editor without proper refactoring plugins enabled it seems.

You get context aware search and replace with LSP in Vim too.

Vim has substitution:

%s/thingamabob/doodad/g

You can put regexes in there, so for 99% of cases you're fine. In neovim (but not in vim) this will also show you a "multicaret" UI.

This is also just one mode of sed, so if you need to do this across multiple files you can just run sed.

Semantic stuff like refactoring is done through LSP.

ast-grep is a fabulous tool imo. I'm generally happier doing a large change at the commandline anyhow.

What do you all think about this? I spent a lot of time on it last year and then put it on the backburner but I was thinking of updating some of the levels to reflect this Practical Vim Command Workflow.

https://www.vimarcade.com/

This is great! Consider adding ":n" for "next lesson". As in - not having to grab the mouse every few seconds to go to the next lesson on a keyboard-only tutorial would be nice.

Oh, I think I wasn't clear on what "Start" would do. At some point the ball stopped moving but I kept cruising along by clicking the "Proceed" button. Also... not sure what toggle does.

I recently switched to vscode after using vim for over 2 decades. Perhaps I am just getting older, however I now find that hitting 5j or 12k as in the article steals some cognitive bandwidth. I still use vim for looking at log files and quick edits e.g. to config files, and went mode-less for more free form editing like coding.

It may be slower and less efficient to hit the down key 5 times or alt+right a few times however it is also mindless and doesn't take any mental bandwidth. YMMV of course.

Waiting for the visual feedback to tell you where the cursor is, also takes some bandwidth. For example, vscode has this awesome syntax-aware expand-selection feature, but it requires you to repeat the command multiple times and check the results between each press. When applicable, ci{ is better because, despite requiring more mental bandwidth, you know exactly what the result will be.

Why would you hit `5j` when you could just hold `j` down for an extra tenth of a second and then just literally put your finger/cursor on any line you want?

I agree but staying in neovim and using search / or ?

IMO relative numbers for navigation are not the Vi way. The Vi way, is, as you say, mindless.

People who say you're not faster with Vim (untrue anyway) or it doesn't matter are also missing the point. The point of Vim is ergonomics, and not thinking, not speed. It's diminishing cognitive load. Sometimes I like to use Vim with the cursor turned off.

A lot of these are nice, but honestly, why not use the arrow keys? You can prefix them with a number just the same as `hjkl`, and jump around by words with Ctrl, just like you're already used to.

Taking the first example I would instead do: `<UP>f.i<Ctrl+W>this<ESC><End>i;<ESC>`, which is probably a couple more keystrokes but also much less foreign to people today...

Edit: `<UP>f.i<Ctrl+W>this<End>;<ESC>` - no need to end and restart insert mode

The benefit of hjkl is that it keeps your fingers on home row. I see your point that it could be considered dogmatic, though. Personally, I'm a fan of hjkl.

I believe it's just ergonomics. There's no reason to use the arrow keys if your fingers are already on hjkl. The pinky motion is highly impractical, and moving your whole hand is also. Therefore the only reason to use them is because you have the habit, and the idea is to replace that habit while editing with the hjkl keys.

You know, that's fair. I touch type but I also peck, so I don't really notice it. So long as I don't have to go to the number pad or, god forbid, the mouse - it's no difference to me.

No reason but personal preference; here is me using the arrow keys:

https://www.reddit.com/r/unixporn/comments/jtjol5/cinnamon_l...

Of all things people get stubborn about regarding Vim, "use hjkl!" is probably the silliest. The whole notion of text object is meant to make character-wise navigation irrelevant.

Arrow keys suck on most laptop keyboards.

Does anybody here use the number repeating thing and feel like it's faster? I could _never_ make it faster, doesn't matter if I have relative lines or any other combination of settings. I've spent some time deliberately practicing and just gave up. I set my repeat delay very low and repeat rate pretty high, and just end up holding j/k, {/} or some other movement operator.

Maybe I suck at reading quickly, but by the time my eyes move from where I'm reading code to the line numbers, register what the relative number is, and type it (say 15) I could have just held j or } to get there faster. Same with something like d5w. I can't count 5 words, I'll just ctrl+v to get into visual selection and press 'w' until I'm happy and call it a day.

Pretty much the only time I do counting operations is when I'm doing writing macros, at which point I've slowed down enough that counting this doesn't feel that bad.

You don't suck. Vim was built for a time when your TTY might take seconds to update. For example, a shell prompt over a modem. In those circumstances the number motions become more precise and less frustrating with such input lag. The other motions have similar commands and you chain them together, which again saves frustration with a painfully slow prompt.

These days things are (usually) fast enough you don't have to worry about exactness, but it's right there when you are experiencing a bad connection.

Previously I would use 25j/25k to go up and down 25 lines (for e.g.) but I've recently started using a pair of bindings to jump up/down 10 lines at a time. This seems to be striking a nice balance between my natural instinct to simply go up/down toward the desired line and doing it without a bunch of unnecessary keystrokes; I get ~60 lines on screen so I'm usually only a couple of keystrokes away from the line I want. I was finding that a number of lines requiring my right hand to type (e.g. 7-10 on my split KB) meant my right hand was moving up and then back down to the home row for the jk keystroke, which was slow and felt bad. With the 10 line jumps, most of the time, I only need <6 more lines to reach the line I want which my left hand will press leaving my right hand to jk. Seems a silly thing to worry about but doing it often grated on me.

Re. your remarks about d5w: give the t/T and f/F operators a look, if you haven't already. I use these far more than numbered motions when it comes to line based motion. https://unix.stackexchange.com/questions/146824/what-is-the-...

I find that I can 'grok' about four lines. So if I have three lines to delete, I can just type 3dd and not get it wrong. But if I have ten lines to delete, I don't think of it as ten lines, and to be honest I type "shift mouse movement vd".

What threw me off for a long time was trying to combine with j: it's `n+1`dj = `n`dd, and the former is almost never what I want. Since j is down I kept thinking I needed to use `jd`, and that isn't how it works.

Sort of stuck with that for upward line delete, it's never intuitive to me to want to delete three lines up and express it as 2dk. I wish that D was backward, so it would pair with t/T and f/F, but it's an entirely different sort of deletion which I rarely need to combine with a motion. Even for what it does on its own, I use d$ out of habit. There must be a way to remap it, but one of my premises in using vim mode is that the skill transfers well, and changing any of the conventions fights against that.

As a decades-long Vim user, same here, absolutely. Much faster for me to hit j 5 times than to count lines downward in my head. And to use visual mode for deletes etc. rather then precounting in my head beforehand.

> than to count lines downward in my head

:set relativenumber

Once you get used to jumping right to the line it's far quicker. Searching and hopping can be quite quick _providing_ there's something unique to jump to, otherwise it can be tedious.

I have used number prefixes for repeating a very pervasive change that has to be done 1000s of times. When you're in that situation no other editor is any good and it's particularly useful for a complicated change which you record as a macro.

Typically your macro starts with a regexp search for the next item to change then you have all your editing commands (including arrow keys and inserts and replaces and whatever) - a quite complicated macro, then you stop recording your macro and tell vim to do it 1000 times. if 1000 isn't enough then do it 1000 more.

You can end up with junk at the end of your file or other issues but on the whole the ability to do a macro many times is still a fabulously useful feature.

sed usually likes to work on a line-by-line basis whereas macros aren't limited to that so vim with numbers can basically do things that no other tool does.

I'm with you. The page gives "5k 12j" as an example, there's no way in the world it's faster for me to figure out that "12" is the right number faster than through other means.

I have H mapped to `5h`, same for jkl, and that's good enough to do biggish jumps that I can eyeball (JJJJ is very quick to type while being iterative)

I spend about half a second estimating. I think, eh that looks like about 30 lines so I'll go 30k. Then it's "oops I was off by 5 lines", so 5j (or jjjjj like you) and I'm there. Unfortunately if I land where I go on the first try it's bad because my fingers leave the home row for a fist pump. "Yesss!"

The relative number bit actually drives me nuts. Mostly I'm fixing some code error "on line 465" of my code. I open up my spacevim and I'm always at line 0, so I have to gg then 465G and it's irritating. Probably need a better IDE.

> I'm always at line 0

    :set number
    :set relativenumber

With both set, you see the actual line number you're on (e.g. line 465) and all other lines are relative.

Personally I end up copy/pasting in/out of vim enough that I turn off line numbers but... FWIW, there's a way to not have the "always on 0" problem. :)

> The page gives "5k 12j" as an example, there's no way in the world it's faster for me to figure out that "12" is the right number faster than through other means.

If you add `set relativenumber` to your .vimrc, then the nth line up and the nth line down from from your current line will each have an n on the left-hand side. This lets you see at a glance which motion (e.g., `5k` or `12j`) will take you to a given line.

https://jeffkreeftmeijer.com/vim-number/

I never understood relative numbers. To really grok Vi you have to understand that you should minimize steps and looking at the relative line number and typing it in is not ergonomic, it's better to search most often, absolute line number movements are good when referencing a stack trace etc.

I didn't get on with the relative numbers either.

In IdeaVim and VSCode, I've mapped the spacebar in Normal mode to EasyMotion. For jumps that aren't very close, you can land on any character you can see on the screen in 4-ish keystrokes.

I do the same thing I have never understood the use case and it is included in every tutorial aa if it is something used daily.

It’s so much slower to move your eyes and type the number even with relative numbers than it is to just hit w, e or f horizontally or j k vertically.

number + relativenumber is the best combination I found so far for jumping between lines - you know where exactly you are, but jumping n lines up or down is great.

I honestly have no idea how I'm controlling VIM but I only know when I'm trying to help someone in VSCode that I'm thinking: How can you live like this?

And also when I'm making a quick not in Gedit I'm instantly frustrated how much moving around everything is.

But it's just all muscle memory. For example I noticed that I always press CAPSLOCK twice. I have CAPSLOCK mapped to esc, but sometimes it's not so I guess my brain adjusted by always tapping it twice.

I can still remember a time though when it was actually slower with VIM than without it.

VSCode has a great neovim extension, so you can get all its smart IDE stuff plus a full vim environment.

Neovim has plenty of IDE stuff! What do I gain using a horribly bloated Electron app. Maybe there's an argument when you're working in a group that standardized on VSCode. But Neovim is quite popular these days.

I've used the neovim extension using neovim remote and it's not a good experience, the two just clash together too much to make it enjoyable.

I've used the combo for 4+ years now and love it. I find VS code has far better out of the box intellisense, refactoring, language support, etc. and I prefer the IDE style environment rather than (neo)VIM's clunky windowing/buffers/splits etc. and janky GUI windowing shells. But whatever, to each their own.

Fair, to me being able to ctrl-z to a shell, open quickly, be absolutely snappy at all times, etc. is paramount to the Vim experience.

VSCode has nothing on Vim with a good LSP config, granted, it can be overwhelming for beginners, but it's not that hard. It's an investment for sure, OTOH, I'm also a NixOS user :P.

> I honestly have no idea how I'm controlling VIM but I only know when I'm trying to help someone in VSCode that I'm thinking: How can you live like this?

VSCode has many features that make developers' lives easier. The one I'm probably using most is multiple cursor. Many others are useful in specific situations like rectangular selection etc.

You are right about VSCode having a lot of quality of life features. But regarding multiple cursors, for me the “.” key in Vim made them obsolete.

No need to lay down multiple cursors then make an edit when I can just make the edit first and repeat said edit wherever I need it.

"." is wonderful, but let me tell you that I bit down and learned macros a few years back, and boy oh boy has that saved me... so much time. They're complicated, but I can say it's worth it.

This is why for me the best setup is VSCode with a solid VIM extension. You can run NeoVIM directly in VSCode. Best of both worlds.

Oh, embarassing, I used ci" quite often, but always maneuvered to the starting quote beforehand. Didn't know that it just took the next one the line.

Of course, now I wonder how to quickly express "change within 2nd text delimited by ..."

> Of course, now I wonder how to quickly express "change within 2nd text delimited by ..."

c2i"

> Don’t use arrow keys and mouse

No.

Yup; this is an extremely silly thing to say.

First of all, people have arrow keys muscle memory from all other programs. Saying "dump it" is as obnoxious as it is stupid; it only makes enemies and gives a false impression of Vim's power.

Secondly, the mouse provides the fastest method of random access on the screen; even things like EasyMotion only barely reach mouse speed. Such nonsense gives the idea that Vim "should not" be used with a mouse, which again misrepresents Vim.

I would generally argue that mouse is slower. If your hand is already on the mouse it is faster but the act of moving your hand to the mouse introduces quite a bit of latency. I can type a few keystrokes (which is usually all that it takes to move within the screen) in the time that it takes to move my hand to the mouse and locate the cursor...

(But if you want to use a mouse, use a mouse! Choice is amazing!)

Develop new muscle memory, having to move your hand off the home row to the arrow keys is an absolute waste, god help the people using a pinky finger. Secondly, I would argue disabling the mouse in vim is commonplace.

Nah, if I see something on screen I want to go to, I type /thing_I_want_to_go_to<enter>. I finish that before I would even touch the mouse with my palm (or touchpad with my fingers) because I never have to leave home row.

You know, when you learn something new you don't necessarily dump the previous experience. Also it took me just around an hour to get used to hjkl back then, why there's so much moaning about it?

Thanks for your valuable input.

Self promotion (in the form of a video I made anyway if that counts).

I did a video that explains some of the ways I use Vim as a non beginner. It covers some of what's in the article, but more around what I'm thinking about when I'm doing them: https://youtu.be/N__lwGR2kdA?si=7Nqc7BGGkaqJr5J8

I use vim every day and use a completely different workflow that heavily relies on searching and (gasp!) mouse mode.

I like “hjkl” movement for nearby characters but the idea of typing numbers to move around a document (e.g. “13k”, “4w”,…) has always baffled me. If something is more than a few lines away I either search for it and go directly or use the mouse to scroll to it.

If you have relative line numbers on, you do "go directly to it" by eg 13k. Yes, you may not land on exactly the spot you wanted to, but that's also just a few characters away.

Searching also has a similar problem where you might land on an earlier match, so it's not perfect either.

Mouse to scroll (scroll not jump?) just feels much slower to me than any of the other solutions.

The trick is to set both number, and relative number. You then get line numbers in the side. The line your cursor is on is the absolute line, but above and below them are offsets. Makes jumping up/down lines easy. So the cursor sitting on line 4 of a file looks like this

     3 a line
     2 another line
     1 a third line
   4   foo
     1 bar
     2 bazz
     3 fizz buzz

As far as jumping words, I personally feel that it's easy enough to eyeball.

edit: I see that they have the note 'There are line number and relative line number on the left.' in the post.

I don't like number because it makes it harder to copy-paste from vim. LOL

(Although I've now left copy-pastability behind a bit with `list listchars=tab:··▸`... Maybe I should try them again)

That's why I set the vim copy-paste buffer to the operating system clipboard. So you can use visual select and y/x.

... huh! Today I learned that visual selecting throws stuff in PRIMARY. (and also "* "+)

That's helpful for sure :) unfortunately I'm often running vim on a remote system though

I also rely heavily on search. When editing code, I am frequently looking to modify a string of characters somewhere in the middle of a line. Navigating firstly to the correct line and then also the correct position within that line is probably going to require several keystrokes anyway so why not just use search to go there directly?

After searching I usually press n for next and N for previous to move around, without having to use the mouse. But it does leave me occasionally baffled as to which function I am looking at when the functions are too long and it’s all the same get/list/update - looking at you Django Rest Framework.

I never use number prefixes. I'm on a keyboard layout where I have to press shift to get numbers, and as you say it's unergonomic. Jumping to characters with f or t and word jumps at much more useful. Searches for more distant things.

I frown on rule 3. Ctrl-D or other Ctrl commands can be mistakenly be sent to your session and oops. Bad things will happen. I train my muscle memory on %s global substitutes and other good tid-bits in the article.

One that I don't use enough:

$vim my_file.c +321 (open vim on line 321)

I like to use vimium with firefox: https://github.com/philc/vimium

Probably my best ergonomic change is remapping CAPS LOCK to CTRL. It makes every <c-XYZ> better, and you can use <c-[> as ESC. Do your pinky a favor!

ctrl v (visual mode) -> highlight lines you want to change -> shift i -> add whatever you want to the line -> escape -> Gets applied to all highlighted lines.

Surprised at how many vim users I run into don't seem to use visual mode that often, stuff like this is fantastic for commenting out multiple lines at once or aligning "=" signs in stuff like terraform.

does anyone know a I don't know module or extension for vim that jumps to a text based file browser.

one that I can navigate with keys up/down, enter to open that file or drill into that folder, backspace to go up a folder

maybe page up/down to flip through pages of files on the screen.

I used to work with iseries and I miss that workflow for editing files through cli

I used netrw in the past but I switched to oil.nvim [1]. I highly recommend it. It lets you edit the your files and directories like a vim buffer. It also supports lsp rename which convenient.

[1] https://github.com/stevearc/oil.nvim

I used to use neo-tree but at this point I've settled into using netrw which is the default file browser. Just open vim in a directory rather than a file and you will boot right into netrw.

https://vonheikemen.github.io/devlog/tools/using-netrw-vim-b...

Netrw is quite good. Oil.nvim is by far the best if you're willing to monkey with a plugin.

I switched from netrw to NERDtree because netrw had mysterious bugs on macOS and I wanted a consistent interface. I'm not in love with it, but it does what I want.

I prefer to have nerdtree because it can be used like regular file explorer tree in an IDE.

When screen sharing with a colleague who might be unfamiliar with vim, it is easy for them to help us navigate if they see a tree compared to the magic of ctrl-p/fzf fuzzy search based on their hints.

Something like this maybe? https://github.com/luukvbaal/nnn.nvim

https://github.com/nvim-neo-tree/neo-tree.nvim

Is quite popular.

Oil is great: https://github.com/stevearc/oil.nvim

It just treats your file structure as a buffer

:help netrw

vim-vinegar for some netrw extras

:Ex

The gif's/short clips of each situation were a good way to present that information.

Reply on news.ycombinator.com