7 ms·

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

by johnfn 4y ago

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 https://github.com/easymotion/vim-easymotion [2]: https://github.com/justinmk/vim-sneak https://github.com/justinmk/vim-sneak

WhyNotHugo 4y ago
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.
airtonix 4y ago
ravishi 4y ago
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.
porphyra 4y ago
Well, the readme does mention that it's similar to Sneak.
ip26 4y ago
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.
- jasonm23 4y ago
  > 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.
- vidyesh 4y ago
  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 https://github.com/phaazon/hop.nvim
- dkersten 4y ago
  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.
- WhyNotHugo 4y ago
  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).
latifk 4y ago
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 https://github.com/wellle/targets.vim
newleapuser 4y ago
> 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/imi20k9/?utm_source=reddit&utm_medium=web2x&context=3 https://www.reddit.com/r/neovim/comments/x25wmb/comment/imi2...
comfypotato 4y ago
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.
- ungamedplayer 4y ago
  Got a reference to link hints, it's not so searchable
  - comfypotato 4y ago
    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://vimium.github.io/ .
  - masukomi 4y ago
    https://github.com/abo-abo/avy https://github.com/abo-abo/avy googled for `"emacs" "avy" "package"` was the 1st result. ;)
- ungamedplayer 4y ago
  Oh, sorry on first read I thought link hints was an avy plugins, not the category.
  - comfypotato 4y ago
    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://vimium.github.io/ .
douglee650 4y ago
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.
P5fRxh5kUvp2th 4y ago
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.
thrownawayalre 4y ago
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
- astrobe_ 4y ago
  Nice tips. Personally I have hlsearch turned on and nohlsearch mapped to H because persistent highlighting is sometimes useful, sometimes a bit annoying.
neeasade 4y ago
> 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 https://github.com/abo-abo/avy#avy-goto-char-timer
- d0mine 4y ago
  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 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.
- j2kun 4y ago
  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.
  - derefr 4y ago
    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.
Ferret7446 4y ago
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.
- minusf 4y ago
  > 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)
- doix 4y ago
  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.
  - picardythird 4y ago
    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.
    - 4y ago
stevebmark 4y ago
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.

by johnfn 4y ago

WhyNotHugo 4y ago

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.

airtonix 4y ago

ravishi 4y ago

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.

porphyra 4y ago

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

ip26 4y ago

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.

jasonm23 4y ago
> 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.
vidyesh 4y ago
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 https://github.com/phaazon/hop.nvim
dkersten 4y ago
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.
WhyNotHugo 4y ago
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).

latifk 4y ago

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 https://github.com/wellle/targets.vim

newleapuser 4y ago

> 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/imi20k9/?utm_source=reddit&utm_medium=web2x&context=3 https://www.reddit.com/r/neovim/comments/x25wmb/comment/imi2...

comfypotato 4y ago

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.

ungamedplayer 4y ago
Got a reference to link hints, it's not so searchable
- comfypotato 4y ago
  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://vimium.github.io/ .
- masukomi 4y ago
  https://github.com/abo-abo/avy https://github.com/abo-abo/avy googled for `"emacs" "avy" "package"` was the 1st result. ;)
ungamedplayer 4y ago
Oh, sorry on first read I thought link hints was an avy plugins, not the category.
- comfypotato 4y ago
  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://vimium.github.io/ .

douglee650 4y ago

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.

P5fRxh5kUvp2th 4y ago

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.

thrownawayalre 4y ago

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

astrobe_ 4y ago
Nice tips. Personally I have hlsearch turned on and nohlsearch mapped to H because persistent highlighting is sometimes useful, sometimes a bit annoying.

neeasade 4y ago

> 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 https://github.com/abo-abo/avy#avy-goto-char-timer

d0mine 4y ago
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 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.
j2kun 4y ago
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.
- derefr 4y ago
  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.

Ferret7446 4y ago

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.

minusf 4y ago
> 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)
doix 4y ago
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.
- picardythird 4y ago
  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.
  - 4y ago

stevebmark 4y ago

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.