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

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

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

`: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.

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

   This is a line of text.

   d/text<enter>

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

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

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

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

What beautiful chords at this here fireside chat.

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

You can type "d2;" however.

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

    :1+2,$-2 d

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

You've changed my life

[1] https://github.com/kana/vim-textobj-user

[2] https://github.com/kana/vim-textobj-user/wiki

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

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.

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.

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.

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

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

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

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

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

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

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

   d/fum<C-G><ENTER>

[1]: see :help /_CTRL-G

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

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

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.

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.

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.

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)

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

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.

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.

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.

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