Leap: Neovim’s Answer to the Mouse(github.com)
github.com
Leap: Neovim’s Answer to the Mouse
https://github.com/ggandor/leap.nvim
264 comments
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.
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.
d/text<enter>
v/text<enter>h
(check selection is what I want)
d
> 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 /.
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.)
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 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.
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.
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.
You can type "d2;" however.
Good to know, thank you
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.
[deleted]
I have to personally thank you for that one. Thank you.
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
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:
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:
: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
> d/text<enter>
You've changed my life
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.
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.
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).
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.
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.
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.
[deleted]
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.
: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.
`: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).
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.
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
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.
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
[deleted]
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,
For instance to delete until the second match of fum, type
[1]: see :help /_CTRL-G
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
Nice tips.
Personally I have hlsearch turned on and nohlsearch mapped to H because persistent highlighting is sometimes useful, sometimes a bit annoying.
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. ;)
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 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/ .
> 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
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.
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):
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.
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.
> 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.
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.
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.
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)
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
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...
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.
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.
Reminds me of Avy on emacs.
https://karthinks.com/software/avy-can-do-anything/
https://karthinks.com/software/avy-can-do-anything/
didn't read through the whole readme but it seems leap is avy + substructure jump. and if not, then we should make something like that :)
By "substructure jump" do you mean jumping to a character inside a word? Avy can do that! Compare avy-goto-char and avy-goto-word-1 (or avy-goto-word-0). I have a prefix arg setup working with avy that I stole from ace-jump-mode to jump to either words (avy-goto-word-1), subwords (avy-goto-subword-1, jump to the 'K' in ThisKindOfText, but not the 'x'), or arbitrary characters (avy-goto-char).
If you don't already have muscle memory for ace-jump-mode, which is IIRC why I did it that way, you can just bind the different things to separate combinations, like the avy readme suggests: https://github.com/abo-abo/avy/blob/master/README.md
If you don't already have muscle memory for ace-jump-mode, which is IIRC why I did it that way, you can just bind the different things to separate combinations, like the avy readme suggests: https://github.com/abo-abo/avy/blob/master/README.md
I meant larger file jumps, say you start typing a prefix, avy applies overlays on matches, but you man quickly want to focus on a paragraph and not deal with the whole set of matches.
You can always narrow to a region and use avy on it.
Not ergonomic enough, since you don't really know yet which region you want to be in. In my view, a hydra like structural navigation while having 'avy' on would be better
I think I see why this would be useful for things other than navigation - e.g. using avy to drive replacement or multi-selection, "select all X within this paragraph"-type things. But for navigation by word, for example, I tend to type only 1-2 characters to narrow down the selection, even for a character that is common on-screen. So I don't quite see how it would be faster to do what you're saying. I'm probably still missing something, but I don't know what.
Vim (and recently neovim) has been my editor for around 14 years now! That's about seven hours in this editor every day, and I still find the mouse very convenient for a lot of the moves where the destination cannot be described with one or two keys. I like the idea of this plugin but I don't think it will be a big leap over the use of mouse!
OP and other commenters mentioned years of experience using Vim to support the claim that their usage of the mouse is likely to be necessary.
And while they might be right (or wrong), I'd love to see a good example that demonstrate that claim.
As to myself, I've been using Vim for over 10 years, yet I think it tells nothing of my proficiency with Vim. It's easy enough to become dangerous enough with Vim to surpass any past traditional editor one has used before that (excluding emacs) yet it's just as easy to let one's skills slowly plateau (as I'm surely been prone to over the years). I rarely use a pointing device while in vim/tmux (an exception is when using a lot of splits which I probably should avoid using anyway).
btw the pointing device I'm using is a trackpad mounted on top of my Kinesis Advantage keyboard which means I don't have to take my palm off the keyboard to use the mouse (it is _not_ an argument to say that despite the short distance I almost never use the mouse in vim/tmux but just a side note and a setup that I recommend if you already own a Kinesis Advantage or a similar keyboard)
As to myself, I've been using Vim for over 10 years, yet I think it tells nothing of my proficiency with Vim. It's easy enough to become dangerous enough with Vim to surpass any past traditional editor one has used before that (excluding emacs) yet it's just as easy to let one's skills slowly plateau (as I'm surely been prone to over the years). I rarely use a pointing device while in vim/tmux (an exception is when using a lot of splits which I probably should avoid using anyway).
btw the pointing device I'm using is a trackpad mounted on top of my Kinesis Advantage keyboard which means I don't have to take my palm off the keyboard to use the mouse (it is _not_ an argument to say that despite the short distance I almost never use the mouse in vim/tmux but just a side note and a setup that I recommend if you already own a Kinesis Advantage or a similar keyboard)
I've been using nvim for around 5 years for everything I do on a computer other than web browsing. It feels like I'm missing something here, but why would you ever need a mouse within your terminal? I don't recall never ever needing it :/
For me (Vim user for ~10 years, Kakoune user for ~3 years (iirc), and now Helix user for ~1yr), mouse just feels very natural to skimming. Scroll, scroll, jump, scroll, scroll, scroll, jump. etc
Something about jumping down pages via shortcuts just feels so clunky. I lose all visual sense of my position on the page.
I keep wanting an editor plugin to scroll the page down with a single keystroke. Ie give me the visual anchoring that a scroll wheel does, but with a single key press.
Either way generally i just tent to use my mouse when i'm lightly browsing. Skimming for some code, working through a thought, etc. Jumping down pages just snaps me outa my thought process a lot of the time, because i have no clue where i am, i gotta relearn my position; where my eyes are at. Likewise jumping half a page is a bit better, but still - that instant blink where the top half of the page is gone, the previous bottom is now the top, and the bottom is now entirely new.. it just feels too.. immediate.
Something about jumping down pages via shortcuts just feels so clunky. I lose all visual sense of my position on the page.
I keep wanting an editor plugin to scroll the page down with a single keystroke. Ie give me the visual anchoring that a scroll wheel does, but with a single key press.
Either way generally i just tent to use my mouse when i'm lightly browsing. Skimming for some code, working through a thought, etc. Jumping down pages just snaps me outa my thought process a lot of the time, because i have no clue where i am, i gotta relearn my position; where my eyes are at. Likewise jumping half a page is a bit better, but still - that instant blink where the top half of the page is gone, the previous bottom is now the top, and the bottom is now entirely new.. it just feels too.. immediate.
Neovim has Neoscroll to replace jump scrolls with smooth scrolling:
https://github.com/karb94/neoscroll.nvim
There is a Helix issue (and poll, see last comment) requesting the same feature you could vote on:
https://github.com/helix-editor/helix/issues/1671
https://github.com/karb94/neoscroll.nvim
There is a Helix issue (and poll, see last comment) requesting the same feature you could vote on:
https://github.com/helix-editor/helix/issues/1671
Not OP, but I've been using vim for 20+ years and I get enormous utility out of the mouse wheel for scrolling - especially with a trackpoint.
I spend an enormous amount of time _reading_ code and I want to move up and down quite a lot, but C-U/C-D move too fast (losing mental context) and C-E/C-Y are too slow and RSI-inducing; the wheel very easily allows you to encode an additional "velocity" dimension that the keyboard simply doesn't have.
When reading code, the mouse also allows you to navigate reasonably effectively using only one hand, leaving the other hand free for sipping coffee and taking notes.
I spend an enormous amount of time _reading_ code and I want to move up and down quite a lot, but C-U/C-D move too fast (losing mental context) and C-E/C-Y are too slow and RSI-inducing; the wheel very easily allows you to encode an additional "velocity" dimension that the keyboard simply doesn't have.
When reading code, the mouse also allows you to navigate reasonably effectively using only one hand, leaving the other hand free for sipping coffee and taking notes.
May I suggest two things to make <C-U> and <C-D> more usable?
1. Set 'scroll' to a value you're comfortable with, so that <C-D> and <C-U> move fewer lines.
2. Use a plugin that shows a scrolling animation when you use <C-D>, <C-U>, <C-F> or <C-B>. I use vim-smoothie (https://github.com/psliwka/vim-smoothie).
1. Set 'scroll' to a value you're comfortable with, so that <C-D> and <C-U> move fewer lines.
2. Use a plugin that shows a scrolling animation when you use <C-D>, <C-U>, <C-F> or <C-B>. I use vim-smoothie (https://github.com/psliwka/vim-smoothie).
Have you tried having N lines of context with C-D and C-U? I also found that (half-)page jumps make me lose context, but having some lines on the top or bottom help me keep it.
> leaving the other hand free for sipping coffee and taking notes.
That explains why my coffee ends up cold and abandoned most of the time!
That explains why my coffee ends up cold and abandoned most of the time!
It's not about necessity, it's about convenience. It could be argued that you don't need a mouse to navigate a web page either (there are VIM plugins for web browsers), but a mouse is much more user friendly and easier to use. Sure, you can practice for days with VIM and get really fast at selecting pieces of code in the screen and jumping around with just a few keystrokes... or you can use a mouse.
I like VIM, it is my favourite editor, but I can understand why some people just don't see the appeal. At least for me, the bottlenecks in productivity don't come with how fast I can type code.
I like VIM, it is my favourite editor, but I can understand why some people just don't see the appeal. At least for me, the bottlenecks in productivity don't come with how fast I can type code.
I use the mouse all the time in tmux and nvim, especially for resizing splits, scrolling terminal output, selecting text from tmux, and navigating my nvim file browser. tmux actually has a right click menu that is nice to use occasionally.
I got stuck on a job in Dubai (Government client - they also had us work in trailers on-site - no remote access allowed) with a Remote Desktop jump host where the mouse didn't have any pass-through to my terminal session - which mean I had to work for 8 hours a day without any ability to select/copy/paste with a mouse. I had tmux-installed on the remote hosts and for the next three months, select/cut/copy/paste/resize panes/etc... were done without a mouse. Seven years later, I've never once used a mouse with tmux since then. https://github.com/schasse/tmux-jump is the equivalent plugin that lets you jump anywhere you want on the screen.
Funny, I use tmux all day long because it allows me to navigate out of vim without a mouse. So far I can handle most of my pane resizing needs with prefix + space bar. Otherwise I'll just launch a new window. Maybe I'm just allergic to the mouse.
I tend to have two modes, if I'm actively writing code I rarely use the mouse, but if I'm reading code, I'm mostly using the mouse.
Agreed on resizing. It's not worth it for me to remember those shortcuts when a mouse works faster.
It's really rewarding to set up tmux copy mode in a way that works for you imho.
You don't need a mouse, but it is by far the most ergonomic device we have for navigating to where your eyes are looking at on the screen. This is often useful for selecting text, usually in order to copy/paste or just to highlight.
Try playing some RTS games without a mouse if you want to understand why it's such a useful device in certain situations.
Try playing some RTS games without a mouse if you want to understand why it's such a useful device in certain situations.
Text objects, especially those in neovim which are powered by treesitter, are much more precise than a mouse in a coding context. I can simply select a function, a block scope, a variable assignment, etc.
I use Emacs and occasionally paredit-mode for Lisp structured editing, so I know what you mean.
However, typing a few keys on the keyboard is still not as fast or as automatic as moving the mouse pointer to where your eyes are looking, IF your hand is already on the mouse (such as when scrolling around the code). Of course, if you have to move your hand from the keyboard to the mouse (such as when actively editing), the opposite is usually true.
However, typing a few keys on the keyboard is still not as fast or as automatic as moving the mouse pointer to where your eyes are looking, IF your hand is already on the mouse (such as when scrolling around the code). Of course, if you have to move your hand from the keyboard to the mouse (such as when actively editing), the opposite is usually true.
I have seen vim gurus I absolutely bet can beat your mousing around every single time when it comes to text operations. I'm not saying I can but I am usually not in that big of a hurry when I'm coding, however I am not bad with navigating vi/evil-mode either.
Can the best vim gurus beat an average mouse user? I am certain they can.
Can they beat the best mouse+keyboard gurus? I very much doubt that.
Note again that I'm only talking about navigation - when you're actively editing, you're obviously going to lose too much time moving your hand between mouse and keyboard.
Can they beat the best mouse+keyboard gurus? I very much doubt that.
Note again that I'm only talking about navigation - when you're actively editing, you're obviously going to lose too much time moving your hand between mouse and keyboard.
My biggest mouse use is copying text. Copying in vi is not that bad, but when selecting with the mouse, you don’t have to jump between copy and paste locations, which cuts the cursor navigation by more than half. Sort of like having dual cursors… which is an interesting idea, actually.
Dual cursors is a really good idea.
Like, really good.
Yeah I forgot this is my workaround whenever I use vim through wsl2 to avoid handling the never ending display issues.
I use a mouse regularly for copying and pasting in the terminal (including in vim which I'm sure is sacrilege for some). I use vim almost exclusively as an editor, but I guess old habits die hard and I've always found highlighting and copying with the mouse, plus clicking and pasting to be more natural for me.
I also rely on it for copy pasting purposes but if you have :set number enabled you might, the numbers may get in your way.
This is where I find myself using :set invnumber that I have mapped to F2 so I can quickly get rid of them.
Cut and paste.
I use tmux to do cut and paste, but should I ever need something out of the terminal/browser into the other, or don’t feel like C-b] ‘ing something, the mouse is great.
I use tmux to do cut and paste, but should I ever need something out of the terminal/browser into the other, or don’t feel like C-b] ‘ing something, the mouse is great.
> Cut and paste
If your terminal supports it (iterm, kitty, later versions of gnome-terminal and others) this osc52 plugin is really sweet. It even works over ssh.
https://github.com/ojroques/vim-oscyank/
If your terminal supports it (iterm, kitty, later versions of gnome-terminal and others) this osc52 plugin is really sweet. It even works over ssh.
https://github.com/ojroques/vim-oscyank/
Truth. This has been my experience as well but saying this would upset a lot of people.
People would equate the time it takes to press 4 keys vs moving the mouse but entirely forget the mental compute time of finding a pattern, recognition, selection of first 2 chars, etc. That for me takes more time than moving the mouse.
People would equate the time it takes to press 4 keys vs moving the mouse but entirely forget the mental compute time of finding a pattern, recognition, selection of first 2 chars, etc. That for me takes more time than moving the mouse.
That's just because you haven't internalizes the keypresses so they're second nature. With enough practice most of these operations are practically instant, done before you've had time to move your hand over to the mouse.
Of course the keyword here is "practice". And just using Vim without putting effort into learning these movements doesn't make you good at them, so people using Vim for years/decades without making them second nature and thus prefering the mouse is not too surprising.
Of course the keyword here is "practice". And just using Vim without putting effort into learning these movements doesn't make you good at them, so people using Vim for years/decades without making them second nature and thus prefering the mouse is not too surprising.
I've been using vim daily for many years and I still find mouse faster. Computing doesn't get faster beyond a certain limit. You still need to find and search text where you want to land. That takes 200ms more than I'd like. Pattern finding doesn't get faster beyond a certain point. You can't solve a jigsaw puzzle instantly after 10 years of experience. Pattern recognition and search requires finite time.
Mouse is instant in terms of brain compute.
Mouse is instant in terms of brain compute.
Do pianists think about where the keyboard is? the notes? they really just know from repetition. The same happens with text editors if you commit yourself to them like emacs or vim
Yes that happens, but I am not arguing about whether we get faster from repetition. I am saying that after a sustained practice and repetition, there exists a hard limit. Pianists cannot play at 100000 keys/minute.
I spend solid 6 hours a day on vim. Almost every day. I don't look at the keyboard or what I am typing. I don't even think about what I am typing.
However, searching for 2 letters is a constant time operation and cannot be optimized away with repetition. You still need to go search for a word that starts with "ha" if you're trying to moving to a word "hackernews". THAT takes time and mental compute. This is very different from not looking at keyboard keys or your argument about a pianist.
Whatever that search time is exceeds the ease of using a mouse (for me). Trust me, it is not about practice.
I spend solid 6 hours a day on vim. Almost every day. I don't look at the keyboard or what I am typing. I don't even think about what I am typing.
However, searching for 2 letters is a constant time operation and cannot be optimized away with repetition. You still need to go search for a word that starts with "ha" if you're trying to moving to a word "hackernews". THAT takes time and mental compute. This is very different from not looking at keyboard keys or your argument about a pianist.
Whatever that search time is exceeds the ease of using a mouse (for me). Trust me, it is not about practice.
but the idea of not having to move your hands off the keyboard to reach the mouse sounds like a big leap!
A trackpoint device embedded in the keyboard may or may not be your friend, then.
I use a split keyboard (kinesis advantage) with an apple magic trackpad Velcroed (Command Strip) in the middle. It’s great, esp for scrolling.
The thing I don’t like about EasyMotion like plug-ins is that they require you to react to information which only appears on screen after you start to jump. With Leap it looks like it amortizes the cost of reacting by giving you the information you need one keystroke before you need to use it. I’m still not a fan of having to react though.
My ideal motion plugin would be Cursorless[0], except using the keyboard instead of voice commands. With Cursorless the markers you need to jump to are always visible, so there’s no need to react. Instead of jumping to characters you jump to tokens, so we do not need makers over every character (just above each token).
[0] https://github.com/cursorless-dev/cursorless
My ideal motion plugin would be Cursorless[0], except using the keyboard instead of voice commands. With Cursorless the markers you need to jump to are always visible, so there’s no need to react. Instead of jumping to characters you jump to tokens, so we do not need makers over every character (just above each token).
[0] https://github.com/cursorless-dev/cursorless
I wish eye-tracking hardware worked better. I feel like if it did it would be the ultimate "mouse".
I've seen a few products but, IIRC, the reviews all conclude that the tech isn't there yet.
I've seen a few products but, IIRC, the reviews all conclude that the tech isn't there yet.
I wonder why it's a hard problem? I'm sure it is, but it would be interesting to know the key issues if anyone here has experience with it.
It seems like w/ an image sensor you can track eye vectors and head location relative to screen w/ a degree of certainty. And—much like tracking a rocket position—you could use a Kalman/Particle Filter to get a screen position pretty close to wherever I'm looking on the screen. I'd guess within 3 characters.
Feels like the kind of thing Apple should invest in and revolutionize...
It seems like w/ an image sensor you can track eye vectors and head location relative to screen w/ a degree of certainty. And—much like tracking a rocket position—you could use a Kalman/Particle Filter to get a screen position pretty close to wherever I'm looking on the screen. I'd guess within 3 characters.
Feels like the kind of thing Apple should invest in and revolutionize...
Eye tracking reliably is hard.
First you have the quality of optics. Most computers have very small cameras that are low resolution and prone to noise in situations without ideal lighting.
That makes eyes hard to capture as a whole.
Then you need to figure out eye direction. Eyes flit around a lot (saccade) but you could perhaps smooth it out. But pupils are hard to see anyway through glasses. You better hope people wear large glasses with skinny frames and don’t suffer from very poor eyesight or astigmatism, both which lead to high refractions.
There are actually good products for this like tobi (sp?) etc where you can wear prescription lenses and have IR tracking for your eyes.
but even the , even if you get over the technical issues there’s the UX issue. How do you account for something getting your users attention without changing the input focus there? Let’s say they’re listening to music and a track changes, showing a notification.
And even if you figure all of that out, there’s the privacy angle. People don’t like being monitored constantly.
First you have the quality of optics. Most computers have very small cameras that are low resolution and prone to noise in situations without ideal lighting.
That makes eyes hard to capture as a whole.
Then you need to figure out eye direction. Eyes flit around a lot (saccade) but you could perhaps smooth it out. But pupils are hard to see anyway through glasses. You better hope people wear large glasses with skinny frames and don’t suffer from very poor eyesight or astigmatism, both which lead to high refractions.
There are actually good products for this like tobi (sp?) etc where you can wear prescription lenses and have IR tracking for your eyes.
but even the , even if you get over the technical issues there’s the UX issue. How do you account for something getting your users attention without changing the input focus there? Let’s say they’re listening to music and a track changes, showing a notification.
And even if you figure all of that out, there’s the privacy angle. People don’t like being monitored constantly.
I've been trying to flit my eyes around the screen to get a sense for how fast you'd need to track. Definitely seems pretty fast! At least sample 30Hz I'd bet. I could see how doing all the image processing that quick might be tricky w/out custom hardware (even w/out the glasses problem you mentioned).
For the UX, I was imagining you have to press a button to instruct the computer that "Hey I'd like for you to move my cursor via eye-tracking". That way the cursor only moves when you want it to (same as today w/ a mouse) and isn't constantly moving around when you look around. Press down to have it move cursor to eye-tracked position and stop when you release.
Could possibly decompose the space bar to have that space for that button. Like have 3 mouse buttons where the right side of space bar is: (a) Track my eye movement while I press down and stop when I release, (b) left-click, (c) right click. Then you don't have to leave home row on your keyboard.
Or add one of those IBM Thinkpad mouse knubs somewhere on a keyboard and use those as mouse buttons instead of a mouse itself.
Idk, easy to dream of course. Hard to execute.
For the UX, I was imagining you have to press a button to instruct the computer that "Hey I'd like for you to move my cursor via eye-tracking". That way the cursor only moves when you want it to (same as today w/ a mouse) and isn't constantly moving around when you look around. Press down to have it move cursor to eye-tracked position and stop when you release.
Could possibly decompose the space bar to have that space for that button. Like have 3 mouse buttons where the right side of space bar is: (a) Track my eye movement while I press down and stop when I release, (b) left-click, (c) right click. Then you don't have to leave home row on your keyboard.
Or add one of those IBM Thinkpad mouse knubs somewhere on a keyboard and use those as mouse buttons instead of a mouse itself.
Idk, easy to dream of course. Hard to execute.
So here’s the other rub with using the keyboard to enter the command. Most people , even experienced touch typists, will flit their eyes towards the thing they’re trying to interact with.
Therein lies a big part of the problem with eye based interaction. Our brains move our eyes for a lot of different tasks, saccade to get a constant read of your scene (eyes have very poor resolving power so need to move a lot), they also signify what you’re thinking (there’s a lot of studies in neurolonguistics about eye direction signalling how you’re thinking, but at a base level, you tend to look up or away when you’re pondering).
Anyway not to say it can’t be done. But it’s a fascinating domain at the cross section of UX, technology and neural science.
For what it’s worth, there are VR headsets with dedicated eye trackers built in (PSVR2, certain Vive Pro models, Varjo etc..) and there have been cameras from Canon (in the film days even!) that used eye tracking for autofocus targets.
It’ll be interesting to see how things shape up. Meta have their big keynote on Tuesday where the Quest Pro / Cambria is meant to have eye tracking sensors.
Therein lies a big part of the problem with eye based interaction. Our brains move our eyes for a lot of different tasks, saccade to get a constant read of your scene (eyes have very poor resolving power so need to move a lot), they also signify what you’re thinking (there’s a lot of studies in neurolonguistics about eye direction signalling how you’re thinking, but at a base level, you tend to look up or away when you’re pondering).
Anyway not to say it can’t be done. But it’s a fascinating domain at the cross section of UX, technology and neural science.
For what it’s worth, there are VR headsets with dedicated eye trackers built in (PSVR2, certain Vive Pro models, Varjo etc..) and there have been cameras from Canon (in the film days even!) that used eye tracking for autofocus targets.
It’ll be interesting to see how things shape up. Meta have their big keynote on Tuesday where the Quest Pro / Cambria is meant to have eye tracking sensors.
Looks like mice poll at around 125Hz. High bar.
Maybe you could place 3-4 30-60FPS cheapish CMOS cams around the edge of the screen and stagger their frame captures? You'd get different angles (better for detecting eye vectors) and increase the sampling rate.
You’d likely want IR cameras and IR sensors to flood illuminate the area outside the human visual spectrum
(Can't reply to your other comment for some reason)
Why is the IR part of the spectrum better for the cameras? Is it because if I take an image of my eye and look at the IR part of the spectrum is it just easier to see parts of my eye that determine where it's looking?
Why is the IR part of the spectrum better for the cameras? Is it because if I take an image of my eye and look at the IR part of the spectrum is it just easier to see parts of my eye that determine where it's looking?
IR is better because you can provide illumination via IR flood lighting that isn’t visible by the human eye.
This is effectively how the FaceID system on your iPhone can work regardless of lighting condition.
That means that even in dark situations, you can have much higher quality imaging , albeit in a limited range.
This is effectively how the FaceID system on your iPhone can work regardless of lighting condition.
That means that even in dark situations, you can have much higher quality imaging , albeit in a limited range.
Ah, interesting! So you can ensure you get illumination on the eyes w/out shining annoying, visible light at them. Very cool.
I've worked a little with commercial eye tracking software. It's typically paired with an infrared sensitive camera and IR lighting because the pupil stands out more against the iris under IR light. It also benefits from a rectilinear camera lens and/or software calibrated lens distortion.
Environmental challenges like lighting conditions, glare, whether the user has glasses or hair obscuring their eyes need to be controlled. If the user is looking downwards towards the screen, their eye appears more closed making it hard to accurately find the iris location.
You also need an accurate measure of the position of the head/eyes relative to the camera. So dedicated hardware like a depth camera might be needed for high precision tracking. Depth cameras come with their own set of issues.
The resolution of even a high-res camera versus the change in pupil location for small eye movements means that by the time you crop out the eyes, you might only be working with a very small image (<100pixels or less). Even with subpixel hinting, there's not a lot of detail left. Small errors here and in the head tracking location can cause large errors in the screen position estimation.
Environmental challenges like lighting conditions, glare, whether the user has glasses or hair obscuring their eyes need to be controlled. If the user is looking downwards towards the screen, their eye appears more closed making it hard to accurately find the iris location.
You also need an accurate measure of the position of the head/eyes relative to the camera. So dedicated hardware like a depth camera might be needed for high precision tracking. Depth cameras come with their own set of issues.
The resolution of even a high-res camera versus the change in pupil location for small eye movements means that by the time you crop out the eyes, you might only be working with a very small image (<100pixels or less). Even with subpixel hinting, there's not a lot of detail left. Small errors here and in the head tracking location can cause large errors in the screen position estimation.
Do our eyes ever lock onto (or centre on) a pixel, or even a small group of pixels for any useful amount of time?
I would think our brain is doing some level of motion tracking on a point while our eyes build up a mental image of the local environment.
Pressing virtual UI buttons with eye tracking makes sense, but if my eyes flick to the wrong character in a text file, it's going to wreck my concentration and end up being more effort than tying a vim chord.
I would think our brain is doing some level of motion tracking on a point while our eyes build up a mental image of the local environment.
Pressing virtual UI buttons with eye tracking makes sense, but if my eyes flick to the wrong character in a text file, it's going to wreck my concentration and end up being more effort than tying a vim chord.
In this comment thread, for e.g., you can have your eyes target the [+] or [-] icons, and then click to expand/collapse those. If you had the "eye-track button" you move you eye to [+], tap button, and left click.
The main use case for me is jumping cursor close to some position while text editing. I'm a Vimmer and I typically just want to look somewhere and instantly move my cursor to where I'm looking sometimes. Easymotion style jumping is nice (I use it in fzf menus, for instance). But there's still that slight mental overhead of figuring out what I gotta type in to jump. Or if I use a mouse then I take hands off keyboard, move mouse, hands back on keyboard. Which sounds pretty simple but it's so slow compared to just jumping around in vim w/ hands always on keyboard.
The main use case for me is jumping cursor close to some position while text editing. I'm a Vimmer and I typically just want to look somewhere and instantly move my cursor to where I'm looking sometimes. Easymotion style jumping is nice (I use it in fzf menus, for instance). But there's still that slight mental overhead of figuring out what I gotta type in to jump. Or if I use a mouse then I take hands off keyboard, move mouse, hands back on keyboard. Which sounds pretty simple but it's so slow compared to just jumping around in vim w/ hands always on keyboard.
A friend of mine who worked on eye tracking at Google (before his project was canned) basically said the technology can do exactly this, but there's no market for it at the price point required to do it reliably.
This is how Vimperator did link selection back before Firefox Quantum, except Vimperator wasn't restricted to 2 characters for matching. You could keep typing until there was only 1 match, or select a numeric index at any time. None of the post-Quantum alternatives got it right back when I was searching for a replacement (no idea if there's another since then that's figured it out).
Vimium C (https://github.com/gdh1995/vimium-c) supports link hinting by simply typing a few characters of the link you want to press. It also searches the actual url and alt-text for links without text (such as buttons and icons). I found it by accident looking through its settings and it has by far been the best improvement to my browsing experience since discovering tabs.
I'd dare say that, more often than not, one finds the need to jump locally to the cursor position, and not from one wild corner to another, as depicted in the video.
When I must do long distance jumps: No matter where I'm, the H, L, and M keys will get me to the top, middle, and bottom lines of the window, respectively. gm will get me to the middle of the row. From there on, relative jumps (set rnu), f, and F will do just fine.
But if you still want to target a particular location, just start searching for that text (/ or ?) - the cursor will be positioned there. If not, tap n a bunch of times, and you're there!
No plugin needed - but that's me. See :help motion.txt.
When I must do long distance jumps: No matter where I'm, the H, L, and M keys will get me to the top, middle, and bottom lines of the window, respectively. gm will get me to the middle of the row. From there on, relative jumps (set rnu), f, and F will do just fine.
But if you still want to target a particular location, just start searching for that text (/ or ?) - the cursor will be positioned there. If not, tap n a bunch of times, and you're there!
No plugin needed - but that's me. See :help motion.txt.
I agree -- I've been using vim for 4 years and jumping around has never been a problem. I use `f`, `t` and `/` a lot and usually that's more than enough (son of course `<n>[jk]`).
At this point I'm more bottlenecked for my thinking rather than my motion.
I'd argue it's better to first properly learn the motions rather than installing this plugin.
At this point I'm more bottlenecked for my thinking rather than my motion.
I'd argue it's better to first properly learn the motions rather than installing this plugin.
I find setting the relative line numbering setting to be quite useful as well If I need to be precise. I generally keep my terminal set to 100 wide so I can guesstimate x "letter distance" pretty accurately
This is like Avy (or ace-jump-mode) in Emacs: https://github.com/abo-abo/avy
Emacs' Avy package has the same functionality for the longest time. I'll share my experience. Lots of people like this way of navigation in the Emacs world. I don't. It takes extra mental energy to navigate like this. You need to:
1. Look at where you want to jump to and scan for suitable search patterns.
2. Do a rough calculation to pick the closest semi-unique pattern.
3. Do the search on the pattern.
4. Go over the labels to see which label is the closest to where you want to go.
5. Pick the label to jump.
I just want some dumb muscle memory to navigate to where I want to go. I don't mind type a few extra keystrokes. I don't want to make all these decisions along the way.
1. Look at where you want to jump to and scan for suitable search patterns.
2. Do a rough calculation to pick the closest semi-unique pattern.
3. Do the search on the pattern.
4. Go over the labels to see which label is the closest to where you want to go.
5. Pick the label to jump.
I just want some dumb muscle memory to navigate to where I want to go. I don't mind type a few extra keystrokes. I don't want to make all these decisions along the way.
I feel exactly the same way. I like the idea in theory, but in practice my code files have too many repeating common characters for a two-letter jump to be useful. The only thing that this extension offers that vim's `/` doesn't is the ability to use it as a movement. But in practice I think that it is too finickey. I just enter visual mode, search for my destination, and then apply the operation.
So for the text
So for the text
the quick brown fox jumps over the lazy dog
^
/ can be used as a movement though?
One thing I've been playing around for the longest time is gaze detection. You're already looking at the area you need to jump to, with some dedicated hardware you have it as another type of mark and then you just need to lock it in place, switch directly or any number of other actions. Unfortunately you need a _very_ high resolution set of cameras placed in a known pattern around the screen for that and the hardware just doesn't exist to do it yet.
On the bright side once you have the hardware you get trivial 3d scans of your face for VR conferencing.
On the bright side once you have the hardware you get trivial 3d scans of your face for VR conferencing.
This is a good idea. In addition to the input cursor, have an eye cursor showing on the text tracking where the eyes are looking at. The eye cursor moves to where the eyes focus. Press a special key, like ctrl-space, to set the input cursor to the eye cursor.
The cameras can be calibrated when the eyes focus at the 4 corners of the editor.
For the cameras, may be a lidar would work better? IPhone has these 3D face scan for the longest time for unlocking. Those read the eyes.
Eye tracking HUD for fighter pilot have been working for a long time, so it's doable.
Edit: This page has some info on eye tracking. https://imotions.com/blog/eye-tracking-work/
The cameras can be calibrated when the eyes focus at the 4 corners of the editor.
For the cameras, may be a lidar would work better? IPhone has these 3D face scan for the longest time for unlocking. Those read the eyes.
Eye tracking HUD for fighter pilot have been working for a long time, so it's doable.
Edit: This page has some info on eye tracking. https://imotions.com/blog/eye-tracking-work/
Yes, it's rather more doable if you wear glasses/helmets.
As a two decade VIM user, this idea looks like "VIM for people who still think like mice". The mouse lets one jump to an arbitrary location on the current window. But the real goal is to jump to a specific object, be it a method signature, or variable declaration, or the beginning of the file, or the end of the line, etc, or the next occurrence of a keyword, or the beginning of this if clause, etc. VIM already has provision for getting to these places, and once they are in muscle memory you won't need to break your train of thought to use them.
Don't use VIM like you used Notepad. Use VIM like you use a manual transmission.
Don't use VIM like you used Notepad. Use VIM like you use a manual transmission.
It’s the vim user that is stuck thinking like a mouse/notepad user, because the vim user has an index into the file that needs to be moved (your cursor), whereas the avy user doesn’t have to think about where he’s coming from, it’s all relative to the viewport. The typical emacs user navigates through project-wide greps and jumps, buffer local searches, and things like avy.
Built in targets should be preferred, sure, but there are plenty of situations not covered by those targets.
In that case it’s quite handy to have a motion plugin at your disposal. Or otherwise use plugins that extend the built in targets (like targets.vim)
In that case it’s quite handy to have a motion plugin at your disposal. Or otherwise use plugins that extend the built in targets (like targets.vim)
If you are looking for something similar for vscode, I can recommend https://github.com/metaseed/metago after having tried several similar extensions.
This sucks and it’s the same as EasyMotion from 10 years ago.
Vim is imperative editing. You have to tell the computer how to edit by glueing together small nasty commands. It gives you “Vim problems.” The mouse is arguably a declarative solution. “I declare I want to edit here.” So much nicer and more efficient.
Vim is imperative editing. You have to tell the computer how to edit by glueing together small nasty commands. It gives you “Vim problems.” The mouse is arguably a declarative solution. “I declare I want to edit here.” So much nicer and more efficient.
Would be nice to see a section comparing it to Avy or Ace-jump and how it differs.
Why? If you're using vim you could care less how emacs, intellij etc. do things.
It sounds like something a motivated person should research and write a blog post or article about the different ways of jumping to code in different editors and different plugins. I don't think this is something every single project maintainer should have to research and educate users about, they have far better things to do with their time.
It sounds like something a motivated person should research and write a blog post or article about the different ways of jumping to code in different editors and different plugins. I don't think this is something every single project maintainer should have to research and educate users about, they have far better things to do with their time.
Because it says:
> with the ultimate goal of establishing a new standard interface for moving around in the visible editor
Which make me curious if they came up with a new kind of keyboard only movement paradigm worth my attention as someone that doesn't use Vim anymore, or if it's just Vim getting a feature other editors have had already and I can ignore the announcement since I'm not a Neovim user.
> with the ultimate goal of establishing a new standard interface for moving around in the visible editor
Which make me curious if they came up with a new kind of keyboard only movement paradigm worth my attention as someone that doesn't use Vim anymore, or if it's just Vim getting a feature other editors have had already and I can ignore the announcement since I'm not a Neovim user.
> At the same time, it reduces mental effort to almost zero
I'm curious, why author(s) sure on this? How did they measure 0 here?
Not saying it's not right, but pointing finger over your touch screen and/or mouse for me sounds more natural and less mental efforts than cryptic Vi-like stuff.
I'm curious, why author(s) sure on this? How did they measure 0 here?
Not saying it's not right, but pointing finger over your touch screen and/or mouse for me sounds more natural and less mental efforts than cryptic Vi-like stuff.
> Fennel
So it has come to this... I wonder if Neovim would be the new extensible editor since Fennel is a Lisp.
So it has come to this... I wonder if Neovim would be the new extensible editor since Fennel is a Lisp.
Code browsing tip: the lua/ files are generated from the Fennel sources under fnl/ so you want to read only the latter.
It looks interesting, but I already use Lightspeed (by the same author). Still not sure how this is an upgrade over that, even after reading the docs. Is there a more compelling argument for switching?
From lightspeed's page, and I quote:
For a more lightweight, easier-to-use alternative, check out the author's new, work-in-progress plugin, Leap. It is a streamlined, refined successor of Lightspeed, incorporating all the lessons learned from the predecessor, achieving much better balance between speed, simplicity (of both interface and implementation) and intuitiveness.
Didn't check, dont know.
For a more lightweight, easier-to-use alternative, check out the author's new, work-in-progress plugin, Leap. It is a streamlined, refined successor of Lightspeed, incorporating all the lessons learned from the predecessor, achieving much better balance between speed, simplicity (of both interface and implementation) and intuitiveness.
Didn't check, dont know.
[deleted]
Looks like Leap is the new focus of their development: https://github.com/ggandor/leap.nvim/issues/3
I was in the same boat. What made me switch is Leap supports jumping across panes/windows.
In a similar vein, but voice driven: https://github.com/cursorless-dev/cursorless.
It seems I should probably finally make the jump from vim to Neovim.
Telescope and better LSP support were the killer features for me. I used to use fzf with vim but Code search is a joy with telescope.
<3 glad to hear people are enjoying this combo
Thank you for all the work that you do!
+1 for this combo, they really make some common tasks surefire and pleasant.
Also Treesitter.
Oh I hadn't heard of telescope, thanks!
I hardly used plug-ins, so am not in a position to evaluate, but the author says that Leap is comparable to Sneak for vim.
Ah, thanks! I tried to switch once and stuff broke, so I abandoned it. I think, in general, Neovim is just more actively maintained, so it looks like I'll have to switch at some point anyway.
Bram is consistently updating vim and recently shipped 9.0 which introduces Vim 9 Script. I would say that there is a line being drawn in the sand more distinctly now, though. Those that adopt the new vim script will probably stick with vanilla vim and neovim's team has no plans at this time to support it [1]. And all these lua plugins are only compatible with neovim.
[1] https://github.com/neovim/neovim/issues/13625
[1] https://github.com/neovim/neovim/issues/13625
One of the Neovim developers is working on a transpiler to run Vim9 script in Neovim: https://twitter.com/neovim/status/1575455161186664451
oh, cool! That's great news. It'll prolong the full fracture of the two for a while, at least.
I jumped a year or two ago and it’s been seamless.
Is this inspired by the Canon Cat? I don't see it mentioned.
Vimium, the browser plugin, has a similar functionality to follow links.
Been around since ~2012 via vim-easymotion as well: https://github.com/easymotion/vim-easymotion
Link for others: https://leebyron.com/til/leap
In the other direction, it was reading about leap that got me in to vim in the first place. I loved the idea of being able to just hop from one bit of text on your system to another. A couple of decades later, that’s exactly what I do in neovim.
Been a long time since I read it, but Jeff Reskin’s Humane Interface is a great read on out interactions with the world around us.
Been a long time since I read it, but Jeff Reskin’s Humane Interface is a great read on out interactions with the world around us.
How does this compare to Hop[0]?
[0] https://github.com/phaazon/hop.nvim
[0] https://github.com/phaazon/hop.nvim
Just from skimming the docs, it looks like Leap's target keystrokes are more directly tied to the buffer's text (2 char prefix + optional discriminator), while Hop generates arbitrary labels... I can imagine the former feeling much more fluid, but haven't actually used either.
Hop user here, and have just given leap a quick test.
The difference is that leap displays all labels needed immediately after the first search key has been typed, whereas hop (more typically of jump plugins) progressively changes them as you type (depending on which hop command you're using).
The idea is that reduces the tiny delay while you identify the label on the jump target you're looking at. Say you're searching for one 'function' amongst many. With leap (default shortcuts), the moment you've typed 'sf', everything you need to jump to your target is immediately displayed. With hop, after invoking the command (with a binding to, say HopChar1), each search-narrowing keypress creates new labels which you have to then identify and type.
Seems promising at first glance, but only more usage time will tell if it's worthwhile.
The difference is that leap displays all labels needed immediately after the first search key has been typed, whereas hop (more typically of jump plugins) progressively changes them as you type (depending on which hop command you're using).
The idea is that reduces the tiny delay while you identify the label on the jump target you're looking at. Say you're searching for one 'function' amongst many. With leap (default shortcuts), the moment you've typed 'sf', everything you need to jump to your target is immediately displayed. With hop, after invoking the command (with a binding to, say HopChar1), each search-narrowing keypress creates new labels which you have to then identify and type.
Seems promising at first glance, but only more usage time will tell if it's worthwhile.
I actually use both (though I use hop more often). I use hop to find a specific line, but leap (or lightspeed) to jump to a specific character.
I use hop only for specific characters using `HopChar1`.
Cool to see a project written in Fennel[1]! (a lisp on top of Lua that's unfortunately not quite Clojure[2])
[1]: https://fennel-lang.org/ [2]: https://fennel-lang.org/from-clojure
[1]: https://fennel-lang.org/ [2]: https://fennel-lang.org/from-clojure
I can't get myself to use those leap/easymotion/avy in editors.. but I definitively use this in vimium to jump to link and use that feature a lot in kitty to be able to select text/url/word/file/sha compared to using the mouse it's a life save, I don't think I have ever seen this feature in any other terminal (maybe you can achieve the same thing with screen/tmux scripting but I don't use much multiplexers)
I have a vimrc configuration that is compatible with neovim. This way I can use both editors depending on what is available in the current environment. Additionally, there are things that work better with vim and there are things that work better with neovim, so this way I can easily switch depending on what I need.
The problem now, is that it looks like neovim is migrating to lua configuration. For example, this plugin requires a lua config file. This is a bit unfortunate, because I don't see how I am going to maintain a parallel lua configuration for nvim.
The problem now, is that it looks like neovim is migrating to lua configuration. For example, this plugin requires a lua config file. This is a bit unfortunate, because I don't see how I am going to maintain a parallel lua configuration for nvim.
Have a Neovim config file in Lua that imports / evals your standard Vimrc.
[deleted]
So this is a bit tangential (though I do intend to try this out) but I’m kind of a fanatic for keyboard efficiency and there seem to be a lot of experts on the thread.
I kind of landed on paredit and incremental search in terms of how to be fast on this sort of thing (though I try to spend an hour or two a day in vi to stay sharp on that too, vi/nvim is very powerful).
What might I be missing out on? What’s the hottest of the new hotness in terms of making code fly around efficiently?
I kind of landed on paredit and incremental search in terms of how to be fast on this sort of thing (though I try to spend an hour or two a day in vi to stay sharp on that too, vi/nvim is very powerful).
What might I be missing out on? What’s the hottest of the new hotness in terms of making code fly around efficiently?
I don’t quite understand what you’re asking here.
I’m no expert in the new hotness, but I hope you’re familiar with surround.vim and repeat.vim.
Both of those are by Tim Pope. Check out all his plugins!
I’m no expert in the new hotness, but I hope you’re familiar with surround.vim and repeat.vim.
Both of those are by Tim Pope. Check out all his plugins!
Hopefully I just missed it but I didn’t see one attribution to Jef or Aza Raskin or the Canon Cat. I find it very hard to believe the authors were not aware of that prior work.
explained here https://www.youtube.com/watch?v=o_TlE_U_X3c
Glad to see people are making coarse-grained UI controls like this. Mouses (fine-grained ‘analog’ alternative) under-serves high-efficiency workflows. Like so much innovation has gone into smartphone gestures (even the keyboards have them), that classic desktop drag to point interfaces genuinely seem archaic. Can’t believe we don’t have commercially popular eye tracking yet, or gesture oriented mouse navigation.
Curious how this compares to "jump mode" in `amp`
I don't use amp as my primary editor, but was heavily tempted based on that feature - was really snappy
https://amp.rs/docs/usage/#jump-mode
Also (as others have mentioned here): it'd be great to see a bigger call out to prior art in the readme (and no name conflict with Raskin)
I don't use amp as my primary editor, but was heavily tempted based on that feature - was really snappy
https://amp.rs/docs/usage/#jump-mode
Also (as others have mentioned here): it'd be great to see a bigger call out to prior art in the readme (and no name conflict with Raskin)
>Use your preferred plugin manager. No extra steps needed, besides optionally setting the default keymaps:
>require('leap').set_default_keymaps()
Where/how am I supposed to set this? It's rejected if I just put it in my vimrc as-is even after installing the plugin. Is it a lua snippet? But then where should it be stored?
I have a super minimalist vimrc as it is, so I'd really appreciate more detailed installation instructions...
>require('leap').set_default_keymaps()
Where/how am I supposed to set this? It's rejected if I just put it in my vimrc as-is even after installing the plugin. Is it a lua snippet? But then where should it be stored?
I have a super minimalist vimrc as it is, so I'd really appreciate more detailed installation instructions...
That is a lua expression I believe (which only works in neovim, hence this plugin being neovim only), you can convert your vimrc to init.lua or make a lua block in your vimrc. The "lua<<EOF" method is common in vimrc xref https://github.com/nanotee/nvim-lua-guide#using-lua-from-vim...
Converting to init.lua is a somewhat fun exercise tho. Once you get a little lua in your config it expands and you get more familiar with it
Converting to init.lua is a somewhat fun exercise tho. Once you get a little lua in your config it expands and you get more familiar with it
Thank you very much for this!
> Down the kangaroo hole
Curious expression. The only kangaroos I know of that live in holes are joeys, in their mothers' pouches. Saw three today, one all inside, one poking its head out, and one that hadn't bothered to finish climbing in, one leg hanging out in a way that doesn't look comfortable, but it's common enough it clearly can't be too bad.
Curious expression. The only kangaroos I know of that live in holes are joeys, in their mothers' pouches. Saw three today, one all inside, one poking its head out, and one that hadn't bothered to finish climbing in, one leg hanging out in a way that doesn't look comfortable, but it's common enough it clearly can't be too bad.
I can't stop using IDEs like Clion with Vim key bindings. Clion offers one of the best Rust/C/C++ experiences that Vim, in my opinion, struggles to match.
I'd like to see stuff like this get ported, because this is a game changer.
Can Neovim be used in conjunction with an IDE? I'd like to use the text editing of Vim, but the AST and project navigation power of an IDE.
I'd like to see stuff like this get ported, because this is a game changer.
Can Neovim be used in conjunction with an IDE? I'd like to use the text editing of Vim, but the AST and project navigation power of an IDE.
Neovim has a headless mode that lets you interact with it via a msgpack rpc. So it can act like an editing “backend”.
There are plenty of GUI IDEs that use Neovim as their backends like Oni. You can just google “Neovim GUI” and get a long list of them.
There are plenty of GUI IDEs that use Neovim as their backends like Oni. You can just google “Neovim GUI” and get a long list of them.
Onivim is no more :(
I haven't got very far into it yet, but there's a number of plugins which can nudge neovim towards IDE functionality.
The language server protocol understands the syntax of your language. There are also plugins for autocompletion, and a file tree for fast navigation.
Caveat - long term vim user just starting to dabble into this territory. Have got started with Telescope for fuzzy file search, and Nerdtree for file navigation.
The language server protocol understands the syntax of your language. There are also plugins for autocompletion, and a file tree for fast navigation.
Caveat - long term vim user just starting to dabble into this territory. Have got started with Telescope for fuzzy file search, and Nerdtree for file navigation.
I have been a long time looking for IDE with vim capabilities. Builder just improved its vi mode. Kate and Geany have one. The problem is that they are limited and beyond basic navigation/editing, the whole process of using the full potential of the IDE in vi mode is under documented and you are never really on how to use them effectively.
And Onivim2 is not developped anymore.
Even finding a simple text editor with a vi mode + mouse copy paste is painful. Gvim is sometimes weird and it is not clear how it handles copy pasting, the new gnome's Text Editor has a vim mode but it's kinda hidden IIRC.
Oh and in Kate, I can't insert "g" in vim mode. I have to take time to report that bug some day.
I have a coworker who uses neovim with VS COde: https://marketplace.visualstudio.com/items?itemName=asvetlia...
I think the majority of the functionality in leap can be had in IntelliJ IDE's with the AceJump plugin
If you want vim-like editing in the Jetbrains IDEs you could use the IdeaVim plugin.
Speaking about jetbrains: is there a way to navigate like leap in resharper? I use the shortcuts extensively but this would definitely help avoiding cursor-navigate to the place where I want to be next.
If you're already using IdeaVim there's https://plugins.jetbrains.com/plugin/13360-ideavim-easymotio..., or AceJump (https://plugins.jetbrains.com/plugin/7086-acejump) if you're not, which is what the IdeaVim-EasyMotion leverages in any case.
IdeaVim is great, but it's a 90% solution. It misses some functionality and won't replicate plugins.
I'd like to use NeoVim headlessly and leverage the strengths of both systems.
I'd like to use NeoVim headlessly and leverage the strengths of both systems.
Helix needs a jumping tool, badly.
I've been using the same EasyMotion's similar 2 character jump functionlity for near 5 years now
nmap f <Plug>(easymotion-overwin-f2)Eh, I'd kind of like the reverse, aka "mouse" as first-class citizen in a true vim editor (as opposed to emulated like in Kate or VSCode) Anyone know of anything like this. Classic Ctrl-C etc bindings would be a bonus.
Is this largely the same as `/{c1}{c2}` and using n or N to move between matches?
Seems like it. I see no big advantage over just jumping wherever via search. Also search allows me to quickly look up a different part of the file and immediately jumping back with Escape.
Has anyone ever tried using something else, say a foot, to move a pointer?
I have not tried any of these advanced text input schemes. I want to. Just thinking about this kind of thing led to my, "use a foot?" question.
I have not tried any of these advanced text input schemes. I want to. Just thinking about this kind of thing led to my, "use a foot?" question.
Not for moving the cursor, but I saw the “vim clutch” on here a while ago:
https://github.com/alevchuk/vim-clutch
https://github.com/alevchuk/vim-clutch
I had no idea... This is too cool and makes me want to build some hardware for use with feet!
What are the differences between the end-effector control of toes vs fingers? I suspect that your hands have evolved to specialize in fine motor control (examining fruits, eating stuff, picking out lice, etc.) and feet have evolved to provide locomotive stability. I bet there are major differences in its effectiveness beyond just neural training (those with amputated arms can make do).
Definitely a consideration.
I saw the "clutch" comment above. Something useful can definitely be done. Perhaps both feet together can improve on what is likely a struggle to be useful at first.
Driving comes to mind, and people do have better motor control than they might believe.
One foot for each axis vs both feet on a platform, or leaning into one with heels on the ground could work, and work differently too.
I do not have time right this minute, but I feel building some hardware might be in my future.
This is the sort of thing one needs to try.
In the 90's I modified the code of a spot welder to give me access to many sets of settings with just the foot pedal as input. That's it. Machine offered nothing else, and adding hardware to it was a no-no.
There were three sets of settings, let's call 'em A, B, C.
A quick tap changed settings.
A longer than "quick" tap placed a weld.
Longer than that delivered welds at the same setting in series, spot, spot, spot, etc.
The machine was a 60Hz machine, and each instruction on it's controller took one cycle. Amazingly, it did have a few program flow on foot pedal state type instructions! I remember one could skip a word, jump and basically pause. That might be all of them. Was enough to implement the flow I put above.
It took the shift after I set the code up for me to do it without really thinking about it.
Why do it?
I had several jobs that required parts be handled more than once, and the worst offender needed three settings.
Programming that old controller was like a simple assembly language. Each instruction word had several fields depending on what it did. And the cool part was getting to write the weld! Close electrodes, open or close pressure valve, modulate weld current, loop back to begin, and the like were there.
Doing the three settings job fit into the number of instruction words it could hold, but not by much!
I think feet can do more than we might think, and at least part of this is a design R&D problem.
The rest, if it makes sense at all, is "human didn't do shit with their feet" problem, agreed.
I saw the "clutch" comment above. Something useful can definitely be done. Perhaps both feet together can improve on what is likely a struggle to be useful at first.
Driving comes to mind, and people do have better motor control than they might believe.
One foot for each axis vs both feet on a platform, or leaning into one with heels on the ground could work, and work differently too.
I do not have time right this minute, but I feel building some hardware might be in my future.
This is the sort of thing one needs to try.
In the 90's I modified the code of a spot welder to give me access to many sets of settings with just the foot pedal as input. That's it. Machine offered nothing else, and adding hardware to it was a no-no.
There were three sets of settings, let's call 'em A, B, C.
A quick tap changed settings.
A longer than "quick" tap placed a weld.
Longer than that delivered welds at the same setting in series, spot, spot, spot, etc.
The machine was a 60Hz machine, and each instruction on it's controller took one cycle. Amazingly, it did have a few program flow on foot pedal state type instructions! I remember one could skip a word, jump and basically pause. That might be all of them. Was enough to implement the flow I put above.
It took the shift after I set the code up for me to do it without really thinking about it.
Why do it?
I had several jobs that required parts be handled more than once, and the worst offender needed three settings.
Programming that old controller was like a simple assembly language. Each instruction word had several fields depending on what it did. And the cool part was getting to write the weld! Close electrodes, open or close pressure valve, modulate weld current, loop back to begin, and the like were there.
Doing the three settings job fit into the number of instruction words it could hold, but not by much!
I think feet can do more than we might think, and at least part of this is a design R&D problem.
The rest, if it makes sense at all, is "human didn't do shit with their feet" problem, agreed.
I read the GitHub page with interest, but glazed over at the examples. Full credit to the author; the whole README is well written. But I’d love to see this demonstrated on YouTube.
Might be nice to choose a different name. "Leap" was Jef Raskin's name for incremental search around text documents with the Swyft, Canon Cat and original Macintosh
The heads up visibility, preview, seems potentially very useful.
[deleted]
Is there something akin to this for tmux? It's essentially how I move around a screen but not quite as nice.
Yes - it's brilliant and I use it ~100 times/day when working with tmux.
https://github.com/schasse/tmux-jump
It's key concept is that you jump to the first letter/number of a "word" and then navigate from there, and, the keys in the label are on the home row. 95% of the time it's less than two characters - I've got the plugin mapped to Alt-u (no meta).
A very common keystroke pattern for me is Alt-u, couple characters (jumps to the exact spot on the screen I want to be), [space] (to start selecting) f (for the character I want to go to) and maybe a couple ; (jump to next instance of that letter) to get to where I want to go, [enter] to copy into the copy-buffer.
It's key concept is that you jump to the first letter/number of a "word" and then navigate from there, and, the keys in the label are on the home row. 95% of the time it's less than two characters - I've got the plugin mapped to Alt-u (no meta).
A very common keystroke pattern for me is Alt-u, couple characters (jumps to the exact spot on the screen I want to be), [space] (to start selecting) f (for the character I want to go to) and maybe a couple ; (jump to next instance of that letter) to get to where I want to go, [enter] to copy into the copy-buffer.
I'm half joking, but you could open neovim in your terminal, then open terminal mode in neovim, then open tmux in there and that way you get neovim navigation in your tmux session.
I just tried it and while it can jump between panes in the normal mode using vim keybindings, you have to use tmux keybindings to switch between panes in terminal mode.
I just tried it and while it can jump between panes in the normal mode using vim keybindings, you have to use tmux keybindings to switch between panes in terminal mode.
Have you tried using https://github.com/christoomey/vim-tmux-navigator ? I use it for using <C-hjkl> to move between window/panes in vim/tmux.
I haven’t tried that before. Looks neat. Thanks for sharing.
i just use forward and backward regular expressions to jump around.
it's fast, flexible and basically second nature.
it's fast, flexible and basically second nature.
I've been using vi since 1988 or so, and I've never used a mouse.
cool, kind of like vimium for links
+1 for vimium, I don't know how I used the web without it
I'm using vimium in Chrome for a few weeks. So far my biggest problem with it is pages that capture the cursor and I end up typing movement commands in some random form/gdoc. Also tabs with pages that have it disabled (gmail, githunt's chrome new page) force you to use vanilla tab movement commands.
you know
simple / works just fine for me :P
I think / works well most cases, but is a bit annoying when you have several duplicate character sequences, so you end up having to type more and more of the sequence to discriminate.
That's what 'n' is for. It also doesn't overwrite the 's' keybinding which is already used for substitution. I don't see the point of this plugin for people who are actually familiar with vim's keybindings.
I am aware of “n”. You can be familiar with vim’s keybindings and still appreciate a different way to solve a problem.
Something like Lightspeed lets you zone in on the specific character faster than repeatedly pressing n. Sure, that means installing a plugin, but some people accept that trade off.
Something like Lightspeed lets you zone in on the specific character faster than repeatedly pressing n. Sure, that means installing a plugin, but some people accept that trade off.
you can use mouse in neovim?? :o
Just like in Vim I guess. And while its enabled, it's good to remember that holding shift gives you back the terminal's own mouse/selection handling. Select in Vim and select text in terminal are two different things that are drawn in similar but not identical ways.
> Select in Vim and select text in terminal are two different things
Yup, this is critical if you want to copy stuff out of vim, you generally don't want to accidentally use the terminal selection because you might take any decorations and LF characters not part of the actual file with you. i.e you want to be using vims copy commands not your your terminals context menu. Thankfully enabling mouse makes it override the terminal by default when dragging, but you still need to add a key binding to get it into the system clipboard buffer thingy... I use ctrl-c because i'm not hardcore enough :D
I've also configured vim to draw invisibles as different characters (spaces, tabs, LF), so it makes even less sense to try use the terminal's selection to copy.
Yup, this is critical if you want to copy stuff out of vim, you generally don't want to accidentally use the terminal selection because you might take any decorations and LF characters not part of the actual file with you. i.e you want to be using vims copy commands not your your terminals context menu. Thankfully enabling mouse makes it override the terminal by default when dragging, but you still need to add a key binding to get it into the system clipboard buffer thingy... I use ctrl-c because i'm not hardcore enough :D
I've also configured vim to draw invisibles as different characters (spaces, tabs, LF), so it makes even less sense to try use the terminal's selection to copy.
Oh, I didn’t know that shift reverts the mouse behaviour. I disable mouse because I like to split my normal Mac copy paste etc from what’s going on in vim but I might give that a shot.
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