[HN Gopher] Leap: Neovim's Answer to the Mouse
___________________________________________________________________
Leap: Neovim's Answer to the Mouse
Author : bpierre
Score : 279 points
Date : 2022-10-08 17:18 UTC (5 hours 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.
| 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.
| srik wrote:
| I NEVER use count, because my mental flow is drastically
| hindered by pausing for any form of counting in midst of
| editing; I stay off relative numbers even. In their place, I
| enable a vast number of text objects instead, quite a few
| implemented through the `kana/textobj-user plugin`. Good text
| object serve as a better embodiment of intent and thus map
| better mentally than any method using brute counting. It does
| come at the loss of some precision and speed, but it's a
| small sacrifice for QOL.
|
| [1] https://github.com/kana/vim-textobj-user
|
| [2] https://github.com/kana/vim-textobj-user/wiki
| 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.
| 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 /.
| 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.)
| cassepipe wrote:
| I have to personally thank you for that one. Thank you.
| 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.
| 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!
| 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]
| 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).
| 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
| 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.
| 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.
| 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.
| 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.
| [deleted]
| bmer wrote:
| Related: https://news.ycombinator.com/item?id=21816854
| 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.
| 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 :/
| 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.
| 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.
| 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!
| 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.
| 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.
| 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.
| 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'm using Vim for over 10 years, yet I think
| tells nothing my proficiency with Vim. It's easy to become
| dangerous enough with Vim to surpass any past traditional
| editor one has used before that (excluding emacs) and let your
| skills slowly plateau (as I'm sure I've been doing too).
| 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.
| 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.
| 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.
| dannyobrien wrote:
| I was going to ask -- does anyone know a port to evil/emacs?
| 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
| 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.
| 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.
| 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.
| 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).
| d3nj4l wrote:
| Tridactyl is pretty fucking good.
| cassepipe wrote:
| Using vimium FF. So far it has served me well.
| 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.
| 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.
| 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.
| 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.
| 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.
| mftb wrote:
| +1 for this combo, they really make some common tasks
| surefire and pleasant.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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 :(
| 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.
| 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.
| 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).
| 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.
| 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.
| 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-08 23:00 UTC)