This sounds very similar to EasyMotion, which is an amazing plugin that I hope everyone tries.
EasyMotion allows make any movement, say "w" for forward by word, and will then highlight the beginning of every word on the screen with a "target key". Pressing that target key will take you to that word. Similarly, doing "<EasyMotion Key>j" will do the same, but with every line down from your line (j=down), making jumping to any line, anywhere, as easy as "<EM>j{letter}".
I have EasyMotion bound to the "space" key, and I use a fork of EasyMotion that automatically highlight with 2 letters instead of one (the default is to higlight with one, and if anything is ambiguous, after pressing the first key you'll get another key to press. With this fork, you never have to "press a key then wait", you always press the two keys that appear).
I also have the letters to use mapped to something like: "asdfghjkl", e.g. the homerow keys in order, because if I mistype one of the keys, EasyMotion will take me pretty near.
I should have mentioned EasyMotion in the readme! Or should I.. I should right? I love it, and also recommend everyone to try. But there's just one thing about it: you need to trigger it first to see what you have to press to get to your target. By creating seek I was able to literally make it a three-keystrokes action, I don't need to wait a split second to know what I need to type as the target, I'm already looking at it before I hit even the first key.
So I find EasyMotion great for getting across lines and around the screen, but within the line I think seek is a more fundamental solution.
And I think you should mention EasyMotion in the Readme, I'm probably not the only one around who uses that plugin and many people probably have the same question/
ace-jump-mode is the absolute Emacs nuts and every Emacseers ought to spend the two minutes it takes to understand how it works because it is the biggest time saver ever.
You must be able to type any letter/number on your keyboard without looking at your keyboard that said because the way to use it efficiently consist in first looking where you want move your cursor, then invoking the shortcut while keeping your eyes on your target. That's how you can be really very efficient.
Note that the latest version can also "ace jump" across various Emacs frames (previously it was limited to buffer(s) inside the current frame).
But to be honest the thing posted here for vim is different: Emacs' ace-jump-mode is vim's easymotion and the author of this new vim navigation feature suggest also using easymotion.
But, yeah... Anyone using Emacs or vim and not using ace-jump-mode / easymotion is totally unaware of what he is losing.
Every single time I demonstrate that to coworkers I see a jaw dropping ; )
Yes, EasyMotion is very like the browser vim keybindings. I personally use Luakit which is very minimalistic and dead easy to reprogram your way from interface to behavior.
Another built-in solution to the problem of mismatches when using the jump commands (f, t, F, T) is the use of ; and ,
Semicolon will repeat the last jump command, and comma will repeat it in the opposite direction.
I find this very useful not only for mismatches that I didn't see, but also for help with quickly formatting text. Along side . to repeat an action, it's incredibly fast to use ; to repeat your last jump (like to < for an html tag) and then use . to repeat the last command (like dst, to delete the surrounding html tag). This is a just one example, but it's a quick and easy pattern I use to do things like selectively stripping html tags within a string that has some inline html, or moving around quickly within arrays.
I remapped `;` to `:` (try it, it's fun!) and evolved my character jump usage into just using `/` + two characters of resolution.
So many times I'd do an `f` search like `fs` only to realize the variable `she_sells_sea_shells_by_the_sea_shore` appears between me and my destination. Ugh!
You're missing out on using the normal meaning of ; which is really useful.
I prefer to map the space bar to : instead. The space bar is not usually mapped to anything, so you wouldn't be masking any other function by mapping it.
Also, for jumping long distances, you should really try PreciseJump or EasyMotion. (mentioned elsewhere in this thread)
The problem with ; is that it doesn't work with t. It just leaves the cursor in the same place, because that's exactly what your t command would do if you typed it again.
It's now some years since I used vim regularly but I recall this regularly annoying me when trying to create visual selections. For example, I'd do "vt," (or whatever) expecting the selection to extend to a given point, and then find myself stuck at a , that I hadn't noticed. And then I'd have to move the cursor by hand to fix things, just like you would in some ordinary text editor.
That's odd. With my configuration I can use ; with t and it will skip over an occurrence of the target if it is the next character, like it seems you expect it to behave. I don't know if this has been fixed/improved in Vim itself or by some plugin that I use, but it does seem to be fixed now.
In vim, the ‘new’ behaviour (skipping the target if there would be no motion) is the default, and the original vi behaviour can be selected using cpoptions; see
Oh, you reminded me to mention that ; and , integration is planned! I'll probably have to work something out with tpope's repeat plugin, or if it's simpler I'll just make a self-contained solution. I want seek to act just like a more selective f. The thing about repeating f is that if you are as little as 5 words away from your target you could be looking at 3-4 repeeats, and by then it wouldn't have been anywhere close the most efficient solution--plus it creates a habit of the read-eval-print loop, aka trial and error. Vim should allow you to always say what you want and get there. I find seek useful even in going to the beginning and end of close words, just use spacebar + char or char + spacebar.
I like the idea, but am more reluctant about the keybindings--I use `s` almost every day. More importantly, I'm infatuated with the marriage Vim has between motions and actions-over-a-range, and think it's very weird to have motion commands that are only available after {d, c, y}.
Thanks for the feedback. I know remapping a basic vim key is pretty drastic, but to justify seek's speed I needed an easily accessed key--though I do plan to allow setting it to another key in your vimrc--and substitute quite fits the bill. I'm already using 1s instead of lone s without thinking. And for higher counts it doesn't get in your way.
Regarding the motions with d, c and y, just to clarify the seek motion is available anytime. As for the others, they work similarly to iw, i" &c, and I think these operator pending motions add a great layer of flexibility to vim without needing extra base keys.
Maybe 3 needs to become 42. Maybe x needs to become price. Maybe miapelling needs to become misspelling. I pretty frequently have a one-character thing that needs to be replaced.
Interesting, but I am not willing to surrender a basic key binding like `s` with what can be done with /. It is only an extra key to do the same thing.
You should lower your ambitions and just make this a function one can key bind to a char of their choice.
Have you tried submitting this to vim as a patch instead? I doubt it would be approved, for a good reason. Nice work though.
I actually used to use the single 's' keypress a lot. But at the same time I wasn't happy about that habit, it was often lazy-thinking, instead of using things like cf{char} or even cw, ce. So I committed to use '1s' when I really needed the single substitution, and it worked really well, so I felt I had gained on both sides. Just try and see what you think, you can always remove. And yes I will make it customizable, but I especially wanted to release this first opinionated version exactly to get feedback like this. Thanks.
Never knew about c<space> (and d and y), I think it would be the easiest. Though I'm happy with 1s and now that I think about it, these {operator}<space> beg to be remapped to something else entirely, maybe inner word or the function's name? I'll play around with onoremap <Space> iw
How is this better or different than incremental search? Incremental search means it jumps to the first match as soon as you start typing after '/': you don't need to press enter.
Try this combination of options to get functionality similar to emacs's C-s:
I've had exactly these three settings for a while, and I've just tested and incsearch didn't take to the match without enter. It's a great feature though, but I don't think I'd want it to take me, it would always fire early, say if I would be typing 'th' it would go to 'the' when really I had wanted 'though' some words next.
To the creator: What about all the other plugins and macros that already use "s" ? I'd love to try this out, but remapping basic keys has always led to some other function or mapping or macro suddenly failing.
Why can you not rework the "f" key itself to take 2 keys if pressed in quick succession? "f" waits a millisecond to see if another key is pressed, if not it behaves identically to the default "f", else it uses 2 or even 3.
That's an interesting proposition, I'll see what I can do to offer the alternative of making f ambiguous instead of using s. I don't think it could be the default because most users wouldn't be as quick to type the three letters, at least at first, and it would need to timeout really fast so as to keep f's original responsiveness to single letters.
While I'm normally of the opinion that 's' is almost begging to be remapped, I don't think that this is different enough from '/' to warrant a first-class place. OTOH mapping the Easy Motion trigger from '\\' to 's' might be worth it.
this really is a sorely needed feature.
vi/vim's lack of "seeking" was really one of the main reasons why i switched to emacs. emacs has a really nice seek, which is just ctrl+s and type whatever you are searching for w/o you needing to hit enter, and you are there. then ctrl+s again to the next match or ctrl+r for reverse.
anyhow, i don't use vim anymore but when i do, i'll give it a shot. i know i can't live without seeking, it's such an important part of your arsenal.
yea but unfortunately it's not that good ... think it's better than default search but a still too slow as a mean for code navigation (atleast for my taste). it's mainly due to needing to hit enter, which escapes everything, there should be a way to hit next occurrence and prev without leaving the /search box.
In combination with this it's almost as effective. Personally I'd use ctags and the http://vimdoc.sourceforge.net/htmldoc/tagsrch.html#tag-comma... search functionality of the tags. But I'll give you that normal text searching in emacs is a tiny bit more efficient :)
EasyMotion allows make any movement, say "w" for forward by word, and will then highlight the beginning of every word on the screen with a "target key". Pressing that target key will take you to that word. Similarly, doing "<EasyMotion Key>j" will do the same, but with every line down from your line (j=down), making jumping to any line, anywhere, as easy as "<EM>j{letter}".
I have EasyMotion bound to the "space" key, and I use a fork of EasyMotion that automatically highlight with 2 letters instead of one (the default is to higlight with one, and if anything is ambiguous, after pressing the first key you'll get another key to press. With this fork, you never have to "press a key then wait", you always press the two keys that appear).
I also have the letters to use mapped to something like: "asdfghjkl", e.g. the homerow keys in order, because if I mistype one of the keys, EasyMotion will take me pretty near.