[HN Gopher] Leap: Neovim's Answer to the Mouse
___________________________________________________________________
Leap: Neovim's Answer to the Mouse
Author : bpierre
Score : 572 points
Date : 2022-10-08 17:18 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| johnfn wrote:
| Hm - I can't see how this is functionally significantly different
| than EasyMotion[1] or Sneak[2]. Not a knock on it - just curious
| if I'm missing something.
|
| My problem with these types of plugins is that, although it's a
| bit more annoying to type out a few more characters, with my
| vanilla Vim workflow I can _pre-compute_ the motions in my head -
| I can figure out I need to type d7l or whatever way before I get
| to the point in my editing where I need to, and as I 'm typing it
| out I'm already thinking about what I want to do next. With
| sneak, easymotion, or leap, it looks like I can't actually figure
| out what keys I need to press to get to where I want until I've
| already started the motion. That means I need to take some time
| to read the label, etc. So maybe I've saved a few milliseconds of
| not having to type one or two more keys, but I lose that and more
| by having to parse what to do.
|
| Curious about other experiences and if I'm off base though.
|
| [1]: https://github.com/easymotion/vim-easymotion [2]:
| https://github.com/justinmk/vim-sneak
| newleapuser wrote:
| > 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...
| porphyra wrote:
| Well, the readme does mention that it's similar to Sneak.
| ip26 wrote:
| 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.
| koprulusector wrote:
| 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.
| bee_rider wrote:
| 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.
| oktwtf wrote:
| 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.
| bee_rider wrote:
| 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
| jasonm23 wrote:
| > 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.
| [deleted]
| Izkata wrote:
| Others have mentioned relativenumber, but for horizontal I
| just use search. For example: This is a line
| of text.
|
| If the cursor is on "is" and you want to delete everything
| before "text", this is what I do:
| d/text<enter>
|
| _Any_ movement works for these actions, even searching to
| "select" everything between the cursor and the target. Often
| I'll use visual mode to get a quick confirmation before
| deleting it: v/text<enter>h (check
| selection is what I want) d
|
| The visual mode one isn't exactly the same because one
| additional character, the first "t" in "text", is in the
| visual selection area, hence the "h" to go back one.
| u801e wrote:
| Another approach is to use normal mode to delete a block of
| text you want. For instance, if you want to delete up to
| the line before the line that contains "This is a line of
| text", you could run q: .,/This
| is a line of text/- d
|
| . is the current line. /This is a line of text/ is the line
| that contains it and the - after the regex refers to the
| line immediately above. You could use _ to refer to the
| line immediately after, or -x or +x where x refers to the
| number of lines above or below the line that the regex
| matched.
| koprulusector wrote:
| Never knew about the - or _ as flags for the search
| regex. This is awesome!
| u801e wrote:
| It's not actually a flag to the s command. It's a way to
| modify the address. So, for instance, if you want to
| delete from the third line to the third to last line in
| the file, you could run: :1+2,$-2 d
|
| 1 is the address of the first line in the file and $ is
| the address of the last line in the file. Add 2 to the
| first to get the third line and subtract 2 from the last
| to get the third to last line. The d command deletes the
| lines in the address range.
|
| You can also address lines with a regex, like I did in
| the example in my previous comment. You can even use
| regex addressing for ranges. If you wanted to delete a
| python method definition in between other method
| definitions, you could do something like:
| :/def method_to_delete/,/def/- d
|
| which would start the range with the line that contains
| def method_to_delete and delete lines up to the line
| before the next line that contains the def keyword that
| starts the next method definition.
| minusf wrote:
| > 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 /.
| kevincox wrote:
| 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.
| wyager wrote:
| How does dtt differ from dft?
| aGHz wrote:
| dtt will stop just before the first t character, dft will
| delete the t as well.
| oktwtf wrote:
| 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.)
| amelius wrote:
| 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")
| nyx wrote:
| I think of the t motion as "to", and the f motion as
| "frough" (rhymes with through: "delete frough the second
| t").
| oktwtf wrote:
| I never even thought to numerically increment the action!
|
| What beautiful chords at this here fireside chat.
| zefhous wrote:
| 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.
| oktwtf wrote:
| Oh great, I'll finally have to remove my remap of '; = :'
| never did I investigate to know what I was opting out of.
| cuddlecake wrote:
| Wouldn't just `.` do the same as `d;` in that case?
| amelius wrote:
| Not always, the ";" sets the repetition-count of the
| operation to 1.
|
| You can type "d2;" however.
| cuddlecake wrote:
| Good to know, thank you
| bch wrote:
| Beautiful - the ways I've never considered composing...
| cassepipe wrote:
| I have to personally thank you for that one. Thank you.
| shepherdjerred wrote:
| > d/text<enter>
|
| You've changed my life
| zamalek wrote:
| 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.
| alwillis wrote:
| Neovim has a plug-in for that:
| https://github.com/smjonas/live-command.nvim
| bjeanes wrote:
| Helix too, it seems, though I haven't used either for more
| than 10 minutes each.
| cassepipe wrote:
| 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)
| oktwtf wrote:
| 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!
| vidyesh wrote:
| 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
| WhyNotHugo wrote:
| 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).
| least wrote:
| 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.
| mftb wrote:
| 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.
| atomicnumber3 wrote:
| 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.
| galoisscobi wrote:
| 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.
| lovehashbrowns wrote:
| 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.
| [deleted]
| dkersten wrote:
| 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.
| schoen wrote:
| 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).
| gnubison wrote:
| > 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.
| collegeburner wrote:
| idk i just got the point where i can eyeball distance and
| adjust a little if needed.
| CoolCold wrote:
| I've seen couple of persons good witn counting chars. Out of
| other hundreds who prefer some sort of visual mode
| drbojingle wrote:
| Thats more for macros than anything else imo.
| bern4444 wrote:
| 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.
| spiffytech wrote:
| I don't count, I (under)estimate. "Eh, that looks like about
| 5 words", then I mash keys the rest of the way.
| WhyNotHugo wrote:
| 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.
| latifk wrote:
| 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
| ravishi wrote:
| 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.
| stevebmark wrote:
| 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.
| Ferret7446 wrote:
| Yes, I felt the same back when I used vim+easymotion.
|
| I've also gotten past the mouse allergy phase. Some editing
| operations are just faster/easier with the mouse and it's not
| worth the overhead learning a new plugin to try to optimize it.
|
| Lots of these micro-optimizations are saving dozens of
| milliseconds. All it takes is a couple minutes of overhead from
| learning, setup, or debugging to wipe out an entire lifetime of
| saved time from such micro-optimizations.
| minusf wrote:
| > wipe out an entire lifetime of saved time from such micro-
| optimizations.
|
| besides of not being able to measure this, it's not how i
| look at it.
|
| i pickup and drop plugins and "waste" time on them because if
| we are a "match" it lets me stay in my "editing flow". (which
| doesn't have to be the same as being fast or effective)
| doix wrote:
| Not all time spent is equal. Spending slack time to improve
| efficiency so that you are more efficient during crunch time
| is generally worth it.
|
| > Lots of these micro-optimizations are saving dozens of
| milliseconds
|
| I think you underestimate how much time it takes to move your
| hand to the mouse and move it back to the keyboard. It's at
| least half a second but likely more.
| picardythird wrote:
| 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.
| doix wrote:
| > 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.
| WastingMyTime89 wrote:
| > 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.
| thrownawayalre wrote:
| Same feeling here with easymotion, sneak and others.
|
| The built-in / with hlsearch on enter and nohlsearch on leave,
| together with the built-in <C-G> [1] for next match and <C-T>
| for previous match **while still in /** provides a faster and
| more natural solution because no need to read labels. From
| :help incsearch, set incsearch augroup
| vimrc-incsearch-highlight autocmd! autocmd
| CmdlineEnter /,\? :set hlsearch autocmd CmdlineLeave
| /,\? :set nohlsearch augroup END
|
| From there, type / and search for 1,2,3... characters (however
| many you want) and see the matches on the screen thanks to
| hlsearch being turned on. Go to next/previous match with <C-G>
| or <C-T> as desired. To close the movement, hit enter as usual
| with /.
|
| For instance to delete until the second match of fum, type
| d/fum<C-G><ENTER>
|
| and it is very easy to follow the current match among all
| highlighted matches because the current match has a different
| color.
|
| [1]: see :help /_CTRL-G
| astrobe_ wrote:
| Nice tips.
|
| Personally I have hlsearch turned on and nohlsearch mapped to
| H because persistent highlighting is sometimes useful,
| sometimes a bit annoying.
| douglee650 wrote:
| A wise man once told me, "nothing is more OG than vim". I've
| strayed away from overly custom environments as a kind of side
| inspiration from that.
| P5fRxh5kUvp2th wrote:
| 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.
| neeasade wrote:
| > 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
| j2kun wrote:
| If you type two keys and have to "select a label" as the
| README says, then you have to parse the screen to see what
| actually happened so you can decide what to do next. That
| seems to be what the parent commenter is saying slows one
| down.
|
| This doesn't seem significantly different from, say,
| /<c1><c2><CR> and then hitting n to go to the next match
| until you've found what you want. It's only one more
| character than this project is claiming to require (the extra
| <CR>). With hlsearch enabled it also shows you matches as you
| type.
| derefr wrote:
| 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.
| mandw wrote:
| 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.
| d0mine wrote:
| I'm jumping around on the screen using <leap key> <where to
| go key> -> <hint keys> https://github.com/abo-abo/avy#avy-
| goto-char
|
| This UX does not break my flow (it doesn't require
| focus/conscious thought): 1. Press <leap key>
| + <where to go key> while looking at the place I want to jump
| to 2. Hints are shown instantaneously (while I'm still
| looking at the place). Press <hint keys>. I'm there.
| comfypotato wrote:
| I use avy in emacs. I think it's the same thing more or less.
| To your point, I think it's a balancing act. Does the
| precomputed sequence of actions take longer than the letter-
| processing interruption? If so, use avy. It's an additional
| tool, not a replacement. Every now and then it comes in really
| handy. For example, I occasionally work on files that have a
| lot of repetition. I find myself turning to avy more in this
| scenario. I also use Vimium in the browser. Link hints (the
| same thing as being discussed) are much superior to mouse
| selection.
| ungamedplayer wrote:
| Oh, sorry on first read I thought link hints was an avy
| plugins, not the category.
| comfypotato wrote:
| 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/ .
| ungamedplayer wrote:
| Got a reference to link hints, it's not so searchable
| masukomi wrote:
| https://github.com/abo-abo/avy
|
| googled for `"emacs" "avy" "package"` was the 1st result.
| ;)
| comfypotato wrote:
| 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/ .
| omnimike wrote:
| 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
| chrismorgan wrote:
| > _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.
| [deleted]
| bmer wrote:
| Related: https://news.ycombinator.com/item?id=21816854
| raydiatian wrote:
| 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.
| a-dub wrote:
| i just use forward and backward regular expressions to jump
| around.
|
| it's fast, flexible and basically second nature.
| CoolCold wrote:
| > 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.
| iansinnott wrote:
| 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
| meitham wrote:
| 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!
| yarky wrote:
| 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 :/
| asdkhadsj wrote:
| 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.
| modernerd wrote:
| 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
| version_five wrote:
| 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.
| cassepipe wrote:
| 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.
| tsimionescu wrote:
| 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.
| stjohnswarts wrote:
| 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.
| tsimionescu wrote:
| 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.
| imbnwa wrote:
| 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.
| tsimionescu wrote:
| 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.
| tail_exchange wrote:
| 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.
| looklookatme wrote:
| 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.
| yarky wrote:
| > 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!
| mojifwisi wrote:
| 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).
| VTimofeenko wrote:
| 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.
| ip26 wrote:
| 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.
| yarky wrote:
| Yeah I forgot this is my workaround whenever I use vim
| through wsl2 to avoid handling the never ending display
| issues.
| vonwoodson wrote:
| Dual cursors is a really good idea. Like, really good.
| vonwoodson wrote:
| 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.
| davvid wrote:
| > 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/
| rhinoceraptor wrote:
| 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.
| sva_ wrote:
| It's really rewarding to set up tmux copy mode in a way
| that works for you imho.
| yarky wrote:
| 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.
| rhinoceraptor wrote:
| 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.
| qudat wrote:
| Agreed on resizing. It's not worth it for me to remember
| those shortcuts when a mouse works faster.
| ghshephard wrote:
| 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.
| jalino23 wrote:
| but the idea of not having to move your hands off the keyboard
| to reach the mouse sounds like a big leap!
| ablob wrote:
| A trackpoint device embedded in the keyboard may or may not
| be your friend, then.
| noncoml wrote:
| I used to love the "nipple" on thinkpads for that exact
| reason
| _dain_ wrote:
| They tend to get stuck off-centre for me.
| therealdrag0 wrote:
| I use a split keyboard (kinesis advantage) with an apple
| magic trackpad Velcroed (Command Strip) in the middle. It's
| great, esp for scrolling.
| almog wrote:
| 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)
| systemvoltage wrote:
| 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.
| lawn wrote:
| 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.
| systemvoltage wrote:
| 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.
| stjohnswarts wrote:
| 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
| systemvoltage wrote:
| 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.
| kache_ wrote:
| you know simple / works just fine for me :P
| latifk wrote:
| 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.
| maxk42 wrote:
| 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.
| latifk wrote:
| 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.
| jerry1979 wrote:
| Reminds me of Avy on emacs.
|
| https://karthinks.com/software/avy-can-do-anything/
| agumonkey wrote:
| 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 :)
| wging wrote:
| 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
| agumonkey wrote:
| 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.
| nesarkvechnep wrote:
| You can always narrow to a region and use avy on it.
| dannyobrien wrote:
| I was going to ask -- does anyone know a port to evil/emacs?
| [deleted]
| dingosity wrote:
| 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
| aldanor wrote:
| Helix needs a jumping tool, badly.
| penguin_booze wrote:
| 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.
| etra0 wrote:
| 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.
| stjohnswarts wrote:
| 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
| ww520 wrote:
| 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.
| thrown_22 wrote:
| 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.
| ww520 wrote:
| 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/
| thrown_22 wrote:
| Yes, it's rather more doable if you wear glasses/helmets.
| zwkrt wrote:
| 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 the quick brown fox jumps over
| the lazy dog ^
|
| I know that with sneak I could type `gUzx ` to upper case
| everthing up until 'jumps'. But `v/x <ENTER>U` works just fine,
| and to my neanderthal brain is way less mental overhead. Not to
| mention I get to see what I am doing instead of having to just
| imagine it.
| 0x445442 wrote:
| 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.
| gjvc wrote:
| explained here https://www.youtube.com/watch?v=o_TlE_U_X3c
| Izkata wrote:
| 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).
| edix8899 wrote:
| 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.
| d3nj4l wrote:
| Tridactyl is pretty fucking good.
| cassepipe wrote:
| Using vimium FF. So far it has served me well.
| fulafel wrote:
| Code browsing tip: the lua/ files are generated from the Fennel
| sources under fnl/ so you want to read only the latter.
| [deleted]
| timlod wrote:
| This is like Avy (or ace-jump-mode) in Emacs:
| https://github.com/abo-abo/avy
| rektide wrote:
| The heads up visibility, preview, seems potentially very useful.
| benreesman wrote:
| 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?
| gsinclair wrote:
| 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!
| fzzzy wrote:
| Is this inspired by the Canon Cat? I don't see it mentioned.
| akkartik wrote:
| Link for others: https://leebyron.com/til/leap
| aidos wrote:
| 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.
| rmetzler wrote:
| Vimium, the browser plugin, has a similar functionality to
| follow links.
| capableweb wrote:
| Been around since ~2012 via vim-easymotion as well:
| https://github.com/easymotion/vim-easymotion
| llambda wrote:
| How does this compare to Hop[0]?
|
| [0] https://github.com/phaazon/hop.nvim
| Graziano_M wrote:
| 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.
| cbushko wrote:
| I use hop only for specific characters using `HopChar1`.
| callahad wrote:
| 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.
| aussiesnack wrote:
| 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.
| stavros wrote:
| It seems I should probably finally make the jump from vim to
| Neovim.
| loeg wrote:
| I jumped a year or two ago and it's been seamless.
| JadeNB wrote:
| 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.
| stavros wrote:
| 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.
| least wrote:
| 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
| alwillis wrote:
| One of the Neovim developers is working on a transpiler
| to run Vim9 script in Neovim:
| https://twitter.com/neovim/status/1575455161186664451
| least wrote:
| oh, cool! That's great news. It'll prolong the full
| fracture of the two for a while, at least.
| galoisscobi wrote:
| 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.
| lawn wrote:
| Also Treesitter.
| mftb wrote:
| +1 for this combo, they really make some common tasks
| surefire and pleasant.
| tjdevries wrote:
| <3 glad to hear people are enjoying this combo
| galoisscobi wrote:
| Thank you for all the work that you do!
| stavros wrote:
| Oh I hadn't heard of telescope, thanks!
| googlryas wrote:
| Is there something akin to this for tmux? It's essentially how I
| move around a screen but not quite as nice.
| galoisscobi wrote:
| 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.
| 91edec wrote:
| 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.
| galoisscobi wrote:
| I haven't tried that before. Looks neat. Thanks for
| sharing.
| ghshephard wrote:
| 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.
| jupp0r wrote:
| If you are looking for something similar for vscode, I can
| recommend https://github.com/metaseed/metago after having tried
| several similar extensions.
| fortran77 wrote:
| I've been using vi since 1988 or so, and I've never used a mouse.
| jrm4 wrote:
| 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.
| stevebmark wrote:
| 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.
| xigoi wrote:
| What? "Delete a word" is much more declarative than "delete
| whatever I just dragged over".
| latifk wrote:
| You could've written this comment without the first paragraph.
| Someone put time and effort into this plugin.
| ggerganov wrote:
| 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.
| jitl wrote:
| Have a Neovim config file in Lua that imports / evals your
| standard Vimrc.
| pentaphobe wrote:
| 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)
| Lapsa wrote:
| you can use mouse in neovim?? :o
| kzrdude wrote:
| 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.
| aidos wrote:
| 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.
| tomxor wrote:
| > 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.
| xigoi wrote:
| If you want to copy stuff from Vim, it's better to use "+y
| .
| tomxor wrote:
| Yes that's what I'm referring to +y/+p.
| kzrdude wrote:
| Agree except if you're over mosh (no X forwarding etc.)
| didibus wrote:
| Would be nice to see a section comparing it to Avy or Ace-jump
| and how it differs.
| qbasic_forever wrote:
| 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.
| didibus wrote:
| 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.
| douglee650 wrote:
| Is this largely the same as `/{c1}{c2}` and using n or N to move
| between matches?
| alpaca128 wrote:
| 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.
| simias wrote:
| >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...
| tonto wrote:
| 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
| simias wrote:
| Thank you very much for this!
| echelon wrote:
| 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.
| latifk wrote:
| 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.
| lbotos wrote:
| Onivim is no more :(
| shortlived wrote:
| Source?
| mojifwisi wrote:
| https://github.com/onivim/oni2/issues/3811#issuecomment-9
| 103...
| cassepipe wrote:
| 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.
| jonas-w wrote:
| If you want vim-like editing in the Jetbrains IDEs you could
| use the IdeaVim plugin.
| echelon wrote:
| 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.
| SeriousM wrote:
| 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.
| zehemer wrote:
| 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.
| Symmetry wrote:
| I have a coworker who uses neovim with VS COde:
| https://marketplace.visualstudio.com/items?itemName=asvetlia...
| peteatphylum wrote:
| I think the majority of the functionality in leap can be had in
| IntelliJ IDE's with the AceJump plugin
| benrow wrote:
| 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.
| nathias wrote:
| cool, kind of like vimium for links
| _dain_ wrote:
| +1 for vimium, I don't know how I used the web without it
| karolist wrote:
| 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.
| haiter wrote:
| dotancohen wrote:
| 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.
| nickysielicki wrote:
| 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.
| latifk wrote:
| 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)
| dumpstate wrote:
| In a similar vein, but voice driven:
| https://github.com/cursorless-dev/cursorless.
| ducktective wrote:
| > Fennel
|
| So it has come to this... I wonder if Neovim would be the new
| extensible editor since Fennel is a Lisp.
| ddingus wrote:
| 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.
| lachlan_gray wrote:
| Not for moving the cursor, but I saw the "vim clutch" on here a
| while ago:
|
| https://github.com/alevchuk/vim-clutch
| ddingus wrote:
| I had no idea... This is too cool and makes me want to build
| some hardware for use with feet!
| systemvoltage wrote:
| 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).
| ddingus wrote:
| 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.
| gsinclair wrote:
| 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.
| cgreerrun wrote:
| 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.
| j2kun wrote:
| 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.
| cgreerrun wrote:
| 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...
| dagmx wrote:
| 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.
| cgreerrun wrote:
| 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.
| dagmx wrote:
| 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.
| cgreerrun wrote:
| Looks like mice poll at around 125Hz. High bar.
| cgreerrun wrote:
| 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.
| dagmx wrote:
| You'd likely want IR cameras and IR sensors to flood
| illuminate the area outside the human visual spectrum
| cgreerrun wrote:
| (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?
| dagmx wrote:
| 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.
| cgreerrun wrote:
| Ah, interesting! So you can ensure you get illumination
| on the eyes w/out shining annoying, visible light at
| them. Very cool.
| dhon_ wrote:
| 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.
| teruakohatu wrote:
| 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.
| cgreerrun wrote:
| 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.
| latifk wrote:
| 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?
| isidor3 wrote:
| Looks like Leap is the new focus of their development:
| https://github.com/ggandor/leap.nvim/issues/3
| novosel wrote:
| 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.
| [deleted]
___________________________________________________________________
(page generated 2022-10-09 23:01 UTC)