Hacker News Reader

Comment by johnfn | Hacker News Reader

Hm - I can't see how this is functionally significantly different than EasyMotion[1] or Sneak[2]. Not a knock on it - just curious if I'm missing something.

My problem with these types of plugins is that, although it's a bit more annoying to type out a few more characters, with my vanilla Vim workflow I can pre-compute the motions in my head - I can figure out I need to type d7l or whatever way before I get to the point in my editing where I need to, and as I'm typing it out I'm already thinking about what I want to do next. With sneak, easymotion, or leap, it looks like I can't actually figure out what keys I need to press to get to where I want until I've already started the motion. That means I need to take some time to read the label, etc. So maybe I've saved a few milliseconds of not having to type one or two more keys, but I lose that and more by having to parse what to do.

Curious about other experiences and if I'm off base though.

[1]: https://github.com/easymotion/vim-easymotion [2]: https://github.com/justinmk/vim-sneak

View on HN

I’ve always wondered, how does anyone rapidly compose vi movements like your example? Or d7w, or c9j… I can’t count seven words or nine lines as fast as I can just tap vwwwwwwwd or shift-vjjjjjjjjjc, because in the latter case I only have to pick out whether the cursor has reached the target, allowing me to blast out four w, then three, then two, with increasing precision as I converge.

Counting characters is even worse. It takes me a good second and a half to confirm that “characters” is ten characters.

Others have mentioned relativenumber, but for horizontal I just use search. For example:

   This is a line of text.

If the cursor is on "is" and you want to delete everything before "text", this is what I do:

   d/text<enter>

Any movement works for these actions, even searching to "select" everything between the cursor and the target. Often I'll use visual mode to get a quick confirmation before deleting it:

   v/text<enter>h
   (check selection is what I want)
   d

The visual mode one isn't exactly the same because one additional character, the first "t" in "text", is in the visual selection area, hence the "h" to go back one.

> d/text<enter>

if you have a unique letter, as in this case ("t"), a quicker way is "dtt" (delete till "t") or "ctt" (change till "t"). in case of non unique character it takes a count but that scales badly for me, and i use /.

These discussions are always a gold mine of tips.!

Also I like to use "f" for find followed by the character you wish to move cursor to the character you desire to end up on the present line. (ex. "fl" jumps to the first "l" of the line.)

And you can also type d2ft to delete everything up to and including the second t, for example.

(I personally think of "f" as "find", not "first")

I think of the t motion as "to", and the f motion as "frough" (rhymes with through: "delete frough the second t").

I never even thought to numerically increment the action!

What beautiful chords at this here fireside chat.

There’s also the `;`, which repeats the last movement! So if you did `dft` and didn’t see the extra “t” in the way in the first place, you can then just do `d;`. It’s like `.` but for movement!

I think that’s right anyway, no vim terminal at hand to check myself.

Wouldn't just `.` do the same as `d;` in that case?

Not always, the ";" sets the repetition-count of the operation to 1.

You can type "d2;" however.

Good to know, thank you

Oh great, I’ll finally have to remove my remap of ‘; = :’ never did I investigate to know what I was opting out of.

Not worth it. That remap has saved me more keystrokes than I can reasonably count. But adding the opposite remap for good measure isn't the worst idea.

Beautiful - the ways I’ve never considered composing…

In the case of dtt you can also often repeat it with . if you have a "false positive" before the intended character rather than counting occurances. Not for c but for d if you don't need the yanked text and regular movement.

I have to personally thank you for that one. Thank you.

How does dtt differ from dft?

dtt will stop just before the first t character, dft will delete the t as well.

Another approach is to use normal mode to delete a block of text you want. For instance, if you want to delete up to the line before the line that contains "This is a line of text", you could run

    q:
    .,/This is a line of text/- d

. is the current line. /This is a line of text/ is the line that contains it and the - after the regex refers to the line immediately above. You could use _ to refer to the line immediately after, or -x or +x where x refers to the number of lines above or below the line that the regex matched.

Never knew about the - or _ as flags for the search regex. This is awesome!

It's not actually a flag to the s command. It's a way to modify the address. So, for instance, if you want to delete from the third line to the third to last line in the file, you could run:

    :1+2,$-2 d

1 is the address of the first line in the file and $ is the address of the last line in the file. Add 2 to the first to get the third line and subtract 2 from the last to get the third to last line. The d command deletes the lines in the address range.

You can also address lines with a regex, like I did in the example in my previous comment. You can even use regex addressing for ranges. If you wanted to delete a python method definition in between other method definitions, you could do something like:

  :/def method_to_delete/,/def/- d

which would start the range with the line that contains def method_to_delete and delete lines up to the line before the next line that contains the def keyword that starts the next method definition.

> d/text<enter>

You've changed my life

I use relative line numbers to go to the line I'm interested in, then use f to jump to a char, and comma to jump to the next matching char, or if I want to go inside a paren (say inside {}), I'll do vi{<Esc>. I also generously use f or F to go back and forth, or just '/' to search a few chars for where I want to jump.

Primeagen has a good video about horizontal motions: https://www.youtube.com/watch?v=qZO9A5F6BZs.

> Or d7w, or c9j… I can’t count seven words or nine lines as fast as I can just tap vwwwwwwwd or shift-vjjjjjjjjjc, because in the latter case I only have to pick out whether the cursor has reached the target, allowing me to blast out four w, then three, then two, with increasing precision as I converge.

No one actually counts :) For vertical motions, I use {/} and search; horizontal motions can use w/W/b/B/e/E, t/f/T/F as well. If you’re counting, you’re doing it wrong: big numbers can’t be recognized quickly, small numbers it’s faster to press ‘.’ than to hit the digit.

You could start with something you're sure is too low and then use . to repeat the command. Like d3w and then press . repeatedly until you get close enough that it's one word (dw) or you can see exactly how many it is.

Similarly for lines. 4dd, ., ., ., and so on.

Of course, this only makes sense for deletion, not for changing or for movement (because the . to repeat a command is commonly not what you intended for changes and doesn't apply at all to pure movement actions).

You get easier at doing the math in your head as you practice more. There’s also lots of methods you can use to skip counting altogether. Like using search. d/“ will delete everything between the cursor and the first “ vim finds, for example. Double quotes are easy, though. :) you can do fun stuff like d/x then dW in this case:

This is just an example. Anyway,

To delete from the cursor at T to just before the A in Anyway without counting words.

Contrived example because there’s an even easier method. There are fun ways to do things and it’s satisfying when you figure out a neat method.

I’m with you on the words or character part. As others have said for line numbers using relative numbers makes it easy.

I end up doing stuff like dt( to delete up until the opening parenthesis or ci’ to to delete inside quotes.

Otherwise as you said I’ll spam the keys till I’m at the point where I want.

This is what relative line numbers are useful for. Not so useful for a delete word action, though. If I'm deleting a set of words though that's when something like leap, sneak, etc. can be useful, since it's a bit more descriptive than the t, T, f, and F motions, which will only go to the next instance of that character. You could do something like d/term<CR> to delete to a search term, though.

As others have said I use relative line numbers to prevent counting vertically. Within a line, I use "f" constantly. Using your last example, say I needed to get to the word "characters" and change it, I would, "fc" and "cw". In the case where there just happened to be multiple "c" on that line, I would "fh" and "ciw". I don't like counting either.

Yeah same, t T f and F are by far the most common things I do for both navigating and deleting/copying. But I also mostly only use vim as my "backup editor". For those scenarios where you only have a magnetized needle, a steady hand, and SSH.

You use Kakoune instead. It selects before an action, allowing you to preview whatever you're doing. So you can 10W as an estimate and then, say, 2BD.

Or Helix if you like shiny new things and you can't resist the "written in rust" hype. (I'm joking, it has other benefits over Kakoune, which is already great and more polished right now)

Helix is very nice! I do like snagging the hx bin and getting to work, no need to mess with LSP config till it's working right!

Neovim has a plug-in for that: https://github.com/smjonas/live-command.nvim

Helix too, it seems, though I haven't used either for more than 10 minutes each.

I've mapped a convenient key to

:exec &rnu? "set nu nornu" : "set nonu rnu"

I wish there were vertical line numbers, though. Usually I just eyeball letter jumps (so rather than 7l I'll end up doing 10lhhh).

In practice, I can't say I've ever felt like moving the cursor around takes up an appreciable amount of time. If it does, then it is probably the case that I'm trying to do something manually that would be better macro-ized.

Maybe you could apply several `colorcolumn` markers, possibly every 10 characters to aid in parsing the verticality?

`:set cc=10,20,30,40,50,60,70,80,90`

Might have to change your highlights/colours so it's a bit more subtly, likely theme dependent.

That could work, and is nice because it is possible to do just the statusline or thereabouts. But rnu for columns would be even nicer

Practice really. I occasionally still get something like 31cl wrong, but just undo and do it right (e.g.: 33cl). Note that, by being off by just 2 or 3 characters, I can quickly ~~recount~~ add.

Usually, I'll get it right if it's under 30 characters, and will be off by one or two if it's between 30 and 50.

For normal code though, counting words is way quicker (e.g.: 7cw).

When it comes to rows, `relanumbers` helps a lot, there's no going back.

For larger chunks of text, things like `cif` (change inside function) and `co{` (change outside brackets) help a lot. Again, practice and keeping them in mind.

Also, every time threads like this appear on HN, I learn new stuff. Like, somebody mentioned using `c/X` (change, search, X). Gonna try that next time I need to replace all text leading to X (which is pretty common).

It’s less common for me to use numbers with motions on a single line.

A lot of times I find a landmark on the line I’m working, for example, I see there’s a word with a “C”. Then, say I want to delete everything to that “C” I’ll do dtC. Or I want to delete everything in quotes on the line, I’ll do di”. Or I’ll pick a character, say “ “ (as in a blank space), and do 3f<space>, and if I need to jump more from there I’ll just just comma a couple times if I need.

I will, however, use 30j or 3J to operate across lines, since I have both absolute and relative line numbers turned on. But solely for movement I’m more likely to use HML to initially jump somewhere more than 5 lines, then do something like 4k or 2j to jump the rest of the way.

There was a point of time when I was a pretty efficient vi user, not anymore though. However when I was, I found that in time, with practice, I got very good at estimating how many characters, words and lines things were. So it’s just practice, after a while you can judge how far you need to go without having to count or think about it.

I use hop[1] to jump horizontally. Hop can also be used with any other commands like v, d, c, y etc.

And generally if I know where I want to go, I would just search with / instead of doing jjjjjjjjj

[1] https://github.com/phaazon/hop.nvim

> I can’t count seven words or nine lines as fast as I can just tap vwwwwwwwd

But you can with a little practice then it becomes normal.

For lines it's easiest, and relative line numbers makes it even easier.

But you can take off the training wheels if you just aim to be proficient after a solid day of practice.

idk i just got the point where i can eyeball distance and adjust a little if needed.

I don't count, I (under)estimate. "Eh, that looks like about 5 words", then I mash keys the rest of the way.

I've seen couple of persons good witn counting chars. Out of other hundreds who prefer some sort of visual mode

Thats more for macros than anything else imo.

Same feeling here with easymotion, sneak and others.

The built-in / with hlsearch on enter and nohlsearch on leave, together with the built-in <C-G> [1] for next match and <C-T> for previous match **while still in /** provides a faster and more natural solution because no need to read labels. From :help incsearch,

  set incsearch
  augroup vimrc-incsearch-highlight
   autocmd!
   autocmd CmdlineEnter /,\? :set hlsearch 
   autocmd CmdlineLeave /,\? :set nohlsearch
  augroup END

From there, type / and search for 1,2,3... characters (however many you want) and see the matches on the screen thanks to hlsearch being turned on. Go to next/previous match with <C-G> or <C-T> as desired. To close the movement, hit enter as usual with /.

For instance to delete until the second match of fum, type

   d/fum<C-G><ENTER>

and it is very easy to follow the current match among all highlighted matches because the current match has a different color.

[1]: see :help /_CTRL-G

Nice tips.

Personally I have hlsearch turned on and nohlsearch mapped to H because persistent highlighting is sometimes useful, sometimes a bit annoying.

I use avy in emacs. I think it's the same thing more or less. To your point, I think it's a balancing act. Does the precomputed sequence of actions take longer than the letter-processing interruption? If so, use avy. It's an additional tool, not a replacement. Every now and then it comes in really handy. For example, I occasionally work on files that have a lot of repetition. I find myself turning to avy more in this scenario. I also use Vimium in the browser. Link hints (the same thing as being discussed) are much superior to mouse selection.

Got a reference to link hints, it's not so searchable

I was referring to link hints in Vimium. You press “f” and all of the links on the page can be selected with the keyboard. It’s in the first 30 seconds of the video on this page https://vimium.github.io/ .

https://github.com/abo-abo/avy

googled for `"emacs" "avy" "package"` was the 1st result. ;)

Oh, sorry on first read I thought link hints was an avy plugins, not the category.

> I can't see how this is functionally significantly different than EasyMotion[1] or Sneak[2].

from the readme:

> it maps possible futures, and shows you which key(s) you will need to press before you actually need to do that.

In the preview gif it's showing the matched hintkeys LIVE as you search.

I think this is actually a huge different in UX. I'm using the emacs equivalent in avy, avy-goto-char-timer[1], and that small pause between searching and acting (typing the hints) makes the experience jarring enough that I don't want end up using goto-char-timer in motions that much (only for jumping across windows and panes)

With no delay between <leap key> and <hint key>, the UX of d<leap key><hint key> is much smoother

[1] https://github.com/abo-abo/avy#avy-goto-char-timer

If you type two keys and have to "select a label" as the README says, then you have to parse the screen to see what actually happened so you can decide what to do next. That seems to be what the parent commenter is saying slows one down.

This doesn't seem significantly different from, say, /<c1><c2><CR> and then hitting n to go to the next match until you've found what you want. It's only one more character than this project is claiming to require (the extra <CR>). With hlsearch enabled it also shows you matches as you type.

You don't scan the screen looking for labels. You are looking directly where you want to be and a label should appear over the place you want to go. That is the label you type to jump, you will never even notice the others or scan them.

My understanding is that the "parsing the screen" step is slightly pipelined with the "typing the keys" step, as the labels you have to read/pick between show up after you've typed the first character of the pair — so in the ~300ms it takes you to type the second character, you've already become aware of the labels, and are well on your way to parsing them.

I'm jumping around on the screen using <leap key> <where to go key> -> <hint keys> https://github.com/abo-abo/avy#avy-goto-char

This UX does not break my flow (it doesn't require focus/conscious thought):

  1. Press <leap key> + <where to go key> while looking at the place I want to jump to
  2. Hints are shown instantaneously (while I'm still looking at the place). Press <hint keys>. I'm there.

Yes, I felt the same back when I used vim+easymotion.

I've also gotten past the mouse allergy phase. Some editing operations are just faster/easier with the mouse and it's not worth the overhead learning a new plugin to try to optimize it.

Lots of these micro-optimizations are saving dozens of milliseconds. All it takes is a couple minutes of overhead from learning, setup, or debugging to wipe out an entire lifetime of saved time from such micro-optimizations.

Not all time spent is equal. Spending slack time to improve efficiency so that you are more efficient during crunch time is generally worth it.

> Lots of these micro-optimizations are saving dozens of milliseconds

I think you underestimate how much time it takes to move your hand to the mouse and move it back to the keyboard. It's at least half a second but likely more.

Maybe I’m just bad at Vim (though I use Vim keys anywhere possible), bit I’m starting to wonder if Vim combos crowd mental space that would be better used for programming. It does take a certain amount of mental energy to constantly be computing effecient key combos. And the half seconds of moving the hand to the mouse are mindless, allowing for the brain to remain focused on next steps.

On another note, the productivity I’ve gained from using an actual IDE, particularly for things like moving files, renaming symbols, and other refactoring tasks, has probably saved me far more time and headache than avoiding to use the mouse.

> It does take a certain amount of mental energy to constantly be computing effecient key combos.

I disagree, the only time I'm actually thinking about key combos is if I'm vim-golfing something or trying to create a macro to reformat a large amount of text.

In day-to-day coding I just think about what I want the result to be and it just happens.

> On another note, the productivity I’ve gained from using an actual IDE

Yeah, IDEs with semantic understanding of the underlying language are great. The stuff JetBrains releases is top notch in that regard. I used IntelliJ whilst working on a Kotlin project despite constantly getting pissed off that it didn't work like I wanted it too.

Knowing how to manipulate text for languages that don't have great IDE support is still worth it if you're ever forced to work in such languages. At my previous gig I had to maintain scripts/programs written in csh/bash/TCL/perl/SKILL/python/ruby, knowing vim well made refactoring significantly quicker/easier.

Now days I just write typescript all day so I do get the IDE to do most of the work.

> It does take a certain amount of mental energy to constantly be computing efficient key combos.

Yes but no one is actually computing efficient key combos. Most people just use the movement they are used to (w, e, f, t) and the most common text objects (s, p, ‘, “, ), ], }) when doing operation. That plus repeat will do 95% of what you want. Add markings used with ed ranges and the occasional macro replayed line by line on a visual selection and you can do everything without ever having to think.

> wipe out an entire lifetime of saved time from such micro-optimizations.

besides of not being able to measure this, it's not how i look at it.

i pickup and drop plugins and "waste" time on them because if we are a "match" it lets me stay in my "editing flow". (which doesn't have to be the same as being fast or effective)

I agree and experience the same. This is actually what makes vim's record and repeat so cool. Sometimes as I'm executing something I realizer there is a pattern and start recording. Two attempts later I'm done formatting a big block of text.

You might benefit from targets.vim, it works well with your thought process. It adds a bunch of new really useful editing targets (which should be builtin imo).

https://github.com/wellle/targets.vim

A wise man once told me, "nothing is more OG than vim". I've strayed away from overly custom environments as a kind of side inspiration from that.

> just curious if I'm missing something

yes you do. leap is night and day to aforementioned, took me one search to find this neat comparison: https://www.reddit.com/r/neovim/comments/x25wmb/comment/imi2...

This is the same impression I get when reading the docs for Leap. It's pretty clear I won't be able to know which keys to press until I'm done pressing the first two, so I can't think of the whole thing as a single motion; I've to complete one motion, pause and think, and then continue.

I suppose it's more useful if you're not too well versed in Vim motions though.

Well, the readme does mention that it's similar to Sneak.

This is actually why I've never liked doing things like setting relative line numbers. To use them, you have to actually stop and look at the line numbers, calculate what you need, then type it out. Without them it just flows through the fingers.

This is exactly EasyMotion, a bad solution from 10 years ago. I’m a Vim power user and I’m happy to not use Vim for daily editing. Vim is full of painful “Vim problems” like the one this is trying to solve. The mouse is much more efficient for selection.

Reply on news.ycombinator.com