Tell HN: '' in Vim moves cursor to recent line
14 comments
I use '" (tick, double quote) all the time, after exiting and coming back into a file it jumps back to where I was.
Time travel in vim is insanely cool. ":earlier 5m" undoes changes to the buffer to make it like it was 5 minutes ago. ":later 1m" will travel the other direction.
Also useful in undo/redo is "g-" and "g+" which undo and redo non-linearly. With just "u" and "^r" you can get to where some undo states are reachable, g-/g+ can get you to those missing states.
Time travel in vim is insanely cool. ":earlier 5m" undoes changes to the buffer to make it like it was 5 minutes ago. ":later 1m" will travel the other direction.
Also useful in undo/redo is "g-" and "g+" which undo and redo non-linearly. With just "u" and "^r" you can get to where some undo states are reachable, g-/g+ can get you to those missing states.
Doctor Strange did a specific kind of time travel in a Marvel movie that I want in vim. He did it to an apple, but not the surrounding area. I would like to be able to highlight a selection in vim and just do time travel in that part, so that my changes elsewhere are not reverted. Does that exist?
It exists in emacs. Blew my mind when I first saw it!
What's the feature called?
Apparently “selective undo”: https://www.gnu.org/software/emacs/manual/html_node/emacs/Un...
I've been looking for this in a code editor for so long. I just want to undo inside a specific set of lines, is that so hard?
Right? Ever since I learned it exists in emacs I’ve been frustrated that this isn’t the top priority in every other editor!
'<character> jumps to the location register identified by <character>. ' is just a special register that holds the "last position", and '' then jumps there. You can explicitly set marks using m<character>, and go back using '<character>. For example, 100Gmagg'a
And to be more specific about the OP entry, 'x (apostrophe) moves to the line of location register x, and `x (backtick) moves to the line and column of x.
g; has been more useful for me than this one. It goes to the most recent change location. I edit a little, then move around in the same file for reference or check signatures and then continue editing by going to previous edit location using g;.
Also Ctrl-O for back, and Ctrl-I for forward, are useful.
And '. for line of the most recent change in the current buffer.
And '. for line of the most recent change in the current buffer.
Totally! Thanks for sharing.
This is part of the “marks” functionality of vim, where you can essentially set bookmarks explicitly, and there are some default ones (like going to the last jump which you described here).
Check out the “Marks and positions” part of the cheatsheet here for more useful tricks: https://vim.rtorr.com/
This is part of the “marks” functionality of vim, where you can essentially set bookmarks explicitly, and there are some default ones (like going to the last jump which you described here).
Check out the “Marks and positions” part of the cheatsheet here for more useful tricks: https://vim.rtorr.com/
Best vim cheatsheet I have seen so far. OTOH I haven't looked at one in a while, and back then my understanding of vim may have been insufficient to appreciate other lists.
I've been experimenting a bit with Vim, and so far I'm _really_ not convinced. I know VSCode is slow, but I have an intuitive set of keyboard commands that accomplish 80% of what I need to do throughout the day:
By contrast, in Vim you use $ to move to end of line, and ^ to move to begin of line. Not only is it unintuitive, it requires more strain of my hands/fingers, and I could easily see myself feeling the pain if I used it full time. Unless I switch keyboards or something.
I'm still giving it a shot because everyone raves about how Vim makes them so much faster, but am I crazy for being highly skeptical at this stage?
move to end of line: cmd + right
move to begin of line: cmd + left
move to end of file: cmd + down
move to begin of file: cmd + up
select to begin of line: cmd + shift + left
select to end of line: cmd + shift + right
By contrast, in Vim you use $ to move to end of line, and ^ to move to begin of line. Not only is it unintuitive, it requires more strain of my hands/fingers, and I could easily see myself feeling the pain if I used it full time. Unless I switch keyboards or something.
I'm still giving it a shot because everyone raves about how Vim makes them so much faster, but am I crazy for being highly skeptical at this stage?
> in Vim you use $ to move to end of line, and ^ to move to begin of line. Not only is it unintuitive
To be fair, that is intuitive if you learned regexes before VIM.
The important part is those motion commands compose. If I wanted to visually select up until the end of the line, I can type v$ — if I want to delete everything from this position to the start of the line, I could type d^. In the middle of a word that needs to disappear? diw (delete in-word). Do I want to copy that word? yiw (yank in-word). Eventually, outside of composing macros (another great feature), you don't really think about the underlying letters of finger movements to perform a certain task; you just do it.
It's not for everyone, and it does come with a downside of making every other code editor feel borderline unusable unless it comes with a good VIM plugin (Jetbrains' suite of IDEs are great for this, and VSCode is pretty good).
To be fair, that is intuitive if you learned regexes before VIM.
The important part is those motion commands compose. If I wanted to visually select up until the end of the line, I can type v$ — if I want to delete everything from this position to the start of the line, I could type d^. In the middle of a word that needs to disappear? diw (delete in-word). Do I want to copy that word? yiw (yank in-word). Eventually, outside of composing macros (another great feature), you don't really think about the underlying letters of finger movements to perform a certain task; you just do it.
It's not for everyone, and it does come with a downside of making every other code editor feel borderline unusable unless it comes with a good VIM plugin (Jetbrains' suite of IDEs are great for this, and VSCode is pretty good).
You are not. Only when you start using motions, macro's, jumps (with relative line numbers) etc things got interesting (for me).
The $ and ^ probably come from regex but I agree they feel a bit unergonomic on a standard keyboard. You can remap them if you're really bothered by it.
Personally I tend to use 'A' and 'I' a lot more because I tend to want to insert/append directly after moving anyway. And if I don't: just press escape. A bit of a hack but at this point it's just muscle memory.
And maybe in the end it all just doesn't work for you, and that's fine too! Vim is about ergonomics for a big part, and that is just a very personal thing.
The $ and ^ probably come from regex but I agree they feel a bit unergonomic on a standard keyboard. You can remap them if you're really bothered by it.
Personally I tend to use 'A' and 'I' a lot more because I tend to want to insert/append directly after moving anyway. And if I don't: just press escape. A bit of a hack but at this point it's just muscle memory.
And maybe in the end it all just doesn't work for you, and that's fine too! Vim is about ergonomics for a big part, and that is just a very personal thing.
let me translate:
I have keybindings which i'm comfortable with. Vim has different ones. It requires work and retraining to change?
What keybindings do you use in VSCode to delete to the next slash? In vim I type d t / "delete to slash" how about changing everything within parens ? c i ( "change in parentheses"
how about copying the entire "paragraph" of text? how about cutting the current line and the next 3 to move them elsewhere?
just because THOSE SPECIFIC things aren't as intuitive or "logical" doesn't mean vim isn't built on a foundation of VERY VERY sensible logical (to english speakers) defaults.
People joke about quitting vim ":wq" w = write q = quit and you can write them out in full. :write followed by :quit Yes you have to know about modes and the colon but if you can't wrap your head around modes, you're not going to wrap your head around loops in programming either and thus you don't need vim.
> but am I crazy for being highly skeptical at this stage?
no, and i mean this in the most literal sense, you're just ignorant. You don't know what you don't know and you assume that the one little thing you tried is representative. It's not.
yes, vim has some weird non-intuitive quirks. hjkl - for example - is based on the location of the arrow keys on a keyboard built into a computer that hasn't existed for like 50+ years. But EVERY complex tool (vscode included) has some weird quirks.
I have keybindings which i'm comfortable with. Vim has different ones. It requires work and retraining to change?
What keybindings do you use in VSCode to delete to the next slash? In vim I type d t / "delete to slash" how about changing everything within parens ? c i ( "change in parentheses"
how about copying the entire "paragraph" of text? how about cutting the current line and the next 3 to move them elsewhere?
just because THOSE SPECIFIC things aren't as intuitive or "logical" doesn't mean vim isn't built on a foundation of VERY VERY sensible logical (to english speakers) defaults.
People joke about quitting vim ":wq" w = write q = quit and you can write them out in full. :write followed by :quit Yes you have to know about modes and the colon but if you can't wrap your head around modes, you're not going to wrap your head around loops in programming either and thus you don't need vim.
> but am I crazy for being highly skeptical at this stage?
no, and i mean this in the most literal sense, you're just ignorant. You don't know what you don't know and you assume that the one little thing you tried is representative. It's not.
yes, vim has some weird non-intuitive quirks. hjkl - for example - is based on the location of the arrow keys on a keyboard built into a computer that hasn't existed for like 50+ years. But EVERY complex tool (vscode included) has some weird quirks.
I totally hear ya.
My introduction to keyboard shortcut navigation (like, heavy use of keyboard shortcuts) was through VSCode.
I've been gradually trending towards Vim as another tool, however, full adoption of Vim is not an "all-or-nothing" proposition for me.
VSC already has so much built into it; and all this conversation about not taking your hands away from the home row is BS... my counter argument to those arguments is: plenty of common commands in VIM require pulling your hands off the home row.
One place where VSC could really improve is making the customization of keyboard shortcuts simpler. I already know about recording my keystrokes to find the command and context, but customizing a key chord to a context is less than intuitive. What on earth are the various contexts I could use? A little help would be appreciated, Microsoft.
As far as VIM.... heavy usage leads to greater ability. Years of usage would definitely accelerate coding. For now though, I use it to pop open one-off files for quick checks, simple edits of config files, and the random simple edits.
My introduction to keyboard shortcut navigation (like, heavy use of keyboard shortcuts) was through VSCode.
I've been gradually trending towards Vim as another tool, however, full adoption of Vim is not an "all-or-nothing" proposition for me.
VSC already has so much built into it; and all this conversation about not taking your hands away from the home row is BS... my counter argument to those arguments is: plenty of common commands in VIM require pulling your hands off the home row.
One place where VSC could really improve is making the customization of keyboard shortcuts simpler. I already know about recording my keystrokes to find the command and context, but customizing a key chord to a context is less than intuitive. What on earth are the various contexts I could use? A little help would be appreciated, Microsoft.
As far as VIM.... heavy usage leads to greater ability. Years of usage would definitely accelerate coding. For now though, I use it to pop open one-off files for quick checks, simple edits of config files, and the random simple edits.
> VSC already has so much built into it; and all this conversation about not taking your hands away from the home row is BS.
VSC is a very good tool. And if someone needs to be productive right away, it's easy to get him going. Vim has a steeper learning curve, but it is easy to make it your own, perfectly suited to you and your projects. As you said, it's not one or another. I use VSC now and then, but going back to my Vim setup is always a delight.
The arguments about the home row are valid. With VIM, text on the screen become an extension of your thinking. And your finger and the keyboard are just the medium that connects both. How I do an action is how I think about doing it. Moving around and editing text has the same cognitive load as entering new text. The things that require me to go away from the home row are unusual operations that also require my full focus and attention.
VSC is a very good tool. And if someone needs to be productive right away, it's easy to get him going. Vim has a steeper learning curve, but it is easy to make it your own, perfectly suited to you and your projects. As you said, it's not one or another. I use VSC now and then, but going back to my Vim setup is always a delight.
The arguments about the home row are valid. With VIM, text on the screen become an extension of your thinking. And your finger and the keyboard are just the medium that connects both. How I do an action is how I think about doing it. Moving around and editing text has the same cognitive load as entering new text. The things that require me to go away from the home row are unusual operations that also require my full focus and attention.
Interesting. It's comments and conversations like this that keep VIM on my horizon and keep me working to incorporate more of it in my daily practice.
I will say this: customization of shortcuts in VIM does seem easier than in VSC (strictly regarding the context settings I was complaining about in VSC).
Perhaps in time the utility I find in VIM will grow, given enough effort. Cheers.
I will say this: customization of shortcuts in VIM does seem easier than in VSC (strictly regarding the context settings I was complaining about in VSC).
Perhaps in time the utility I find in VIM will grow, given enough effort. Cheers.
Yes, if you like VSCode, keep using it. I say that everyone's preference is different. As for me, I use both vim (for general editing) and vscode (javascript coding), depending on what I'm working on. As for the keyboard command, I prefer not to use arrow key since it takes my hands off the optimal position as I need to reach for that arrow key, which puts a slight pause in thought of all the code that I'm thinking in my head. Sure a loss of one second may not be much, but when I'm in the flow / zone, I just want to move as fast as possible.
> I'm still giving it a shot because everyone raves about how Vim makes them so much faster, but am I crazy for being highly skeptical at this stage?
You are not crazy. Vim default bindings are less intuitive than windows/macos/gedit/word default bindings which are all about using arrow keys with a combination of ctrl/alt/cmd. There's logic to vim bindings though but it's not the same. The ctrl/alt/cmd combos have equivalent in insert/visual/normal mode and <leader> (a special key, usullay "\") but there's nothing intuitive about those at first.
I think replacing vscode with vim can't be done in one hour. First one has to learn the modes and the bindings then there's the whole compiling/linting/fixing/debugging/custom_macros/snippets/etc to add. I love vim and its modal interface and how it's easier on my joints than default bindings and I can't use vscode without a vim extension but I am not sure I'd invest time in learning it if I had first started using vscode as my main editor. For instance: I am bad at replacing identical chunk of text in vim (I can do visual mode and shift insert and regex replace but I can see how column editing seem easier and looks better in vscode).
my 2ç:
Oh, and I use "0" to position the cursor at the beginning of the line. (and I just noticed by trying out what ^ does that I usually do 0e to position it at first word/character of the line to get the same result).
You are not crazy. Vim default bindings are less intuitive than windows/macos/gedit/word default bindings which are all about using arrow keys with a combination of ctrl/alt/cmd. There's logic to vim bindings though but it's not the same. The ctrl/alt/cmd combos have equivalent in insert/visual/normal mode and <leader> (a special key, usullay "\") but there's nothing intuitive about those at first.
I think replacing vscode with vim can't be done in one hour. First one has to learn the modes and the bindings then there's the whole compiling/linting/fixing/debugging/custom_macros/snippets/etc to add. I love vim and its modal interface and how it's easier on my joints than default bindings and I can't use vscode without a vim extension but I am not sure I'd invest time in learning it if I had first started using vscode as my main editor. For instance: I am bad at replacing identical chunk of text in vim (I can do visual mode and shift insert and regex replace but I can see how column editing seem easier and looks better in vscode).
my 2ç:
Oh, and I use "0" to position the cursor at the beginning of the line. (and I just noticed by trying out what ^ does that I usually do 0e to position it at first word/character of the line to get the same result).
So you will find nothing intuitive in vim until you grok vim[0]. If you want to learn vim, you should accept that as soon as possible. Things are the way they are because they've been that way forever.
Once you learn the keys for certain operations and grok vim, you can combine them in a way that I would argue is actually the most consistent compared to any other editor.
In terms of strain, do you not feel strain moving your hand to the arrow keys every time you do those operations? If you do decide that you like those bindings (personally I avoid arrow keys), you can get those same bindings in vim. FWIW, I use `_` to go to the first none whitespace character in a line, not sure if that makes it any better.
Also the tabs in vim are second to none (only emacs and kakoune are equal). It's actually the biggest thing that annoys me about other editors. VSCode and JetBrains have good enough vim emulation, but their lack of vim-like tabs is my biggest complaint. I never see people advocate for vim tabs in these types of threads, so I've been championing them every time I can :).
[0] https://stackoverflow.com/questions/1218390/what-is-your-mos...
Once you learn the keys for certain operations and grok vim, you can combine them in a way that I would argue is actually the most consistent compared to any other editor.
In terms of strain, do you not feel strain moving your hand to the arrow keys every time you do those operations? If you do decide that you like those bindings (personally I avoid arrow keys), you can get those same bindings in vim. FWIW, I use `_` to go to the first none whitespace character in a line, not sure if that makes it any better.
Also the tabs in vim are second to none (only emacs and kakoune are equal). It's actually the biggest thing that annoys me about other editors. VSCode and JetBrains have good enough vim emulation, but their lack of vim-like tabs is my biggest complaint. I never see people advocate for vim tabs in these types of threads, so I've been championing them every time I can :).
[0] https://stackoverflow.com/questions/1218390/what-is-your-mos...
> Also the tabs in vim are second to none (only emacs and kakoune are equal). It's actually the biggest thing that annoys me about other editors. VSCode and JetBrains have good enough vim emulation, but their lack of vim-like tabs is my biggest complaint. I never see people advocate for vim tabs in these types of threads, so I've been championing them every time I can :).
Are you referring to tabs as labels in the top of the editor or tabs as the key ? If the first, can you elaborate ? I only use tabnew bound as tt and gt/gT to navigate them. I always felt I was missing something but I don't know what. I sometimes do :vsplit to navigate the same file and look at different parts but I don't have buffers with the same content spread across multiple tabs (I am actually bad at buffers, I still see them as just "opened files").
Are you referring to tabs as labels in the top of the editor or tabs as the key ? If the first, can you elaborate ? I only use tabnew bound as tt and gt/gT to navigate them. I always felt I was missing something but I don't know what. I sometimes do :vsplit to navigate the same file and look at different parts but I don't have buffers with the same content spread across multiple tabs (I am actually bad at buffers, I still see them as just "opened files").
Yes, the first, and sure! So the reason tabs are great in vim (and emacs, and you can kinda do the same with kakoune) is because they are collections of windows (which are views of buffers).
Splits are the main thing. Imagine we have 3 files open in splits like this:
When I'm using those editors, I find myself constantly creating and destroying layouts and it drives me insane. Let's say I'm editing some files and want to look at the diff of what I've done so far, in vim I can open a new tab and have diff|original. In VSCode it will open the diff in one of my splits, and since it's a diff, it will be split in 2 as well. On my laptop I can't see anything if my diff|original only takes up half my screen, I have to resize/close splits at that point and then going back to what I was doing is more difficult.
When I'm working on code and writing tests, I'll usually have my tests in one tab and the code in another. Or if someone asks me a question, I can make a new tab, start searching/reading code in there and then quickly go back to where I went. I find it extremely handy for context switching.
> (I am actually bad at buffers, I still see them as just "opened files").
I think that's fine. That's the mental model I have as well, except you can have non-file buffers as well, e.g. for plugins. It's actually another great thing about vim, you have to actively try to break the normal hotkeys, otherwise everything works. You can use the same keys everywhere to navigate around in any plugin (unless they override them).
Splits are the main thing. Imagine we have 3 files open in splits like this:
┌───┬─────┐
│ │ B │
│ A ├─────┤
│ │ C │
└───┴─────┘
When I'm using those editors, I find myself constantly creating and destroying layouts and it drives me insane. Let's say I'm editing some files and want to look at the diff of what I've done so far, in vim I can open a new tab and have diff|original. In VSCode it will open the diff in one of my splits, and since it's a diff, it will be split in 2 as well. On my laptop I can't see anything if my diff|original only takes up half my screen, I have to resize/close splits at that point and then going back to what I was doing is more difficult.
When I'm working on code and writing tests, I'll usually have my tests in one tab and the code in another. Or if someone asks me a question, I can make a new tab, start searching/reading code in there and then quickly go back to where I went. I find it extremely handy for context switching.
> (I am actually bad at buffers, I still see them as just "opened files").
I think that's fine. That's the mental model I have as well, except you can have non-file buffers as well, e.g. for plugins. It's actually another great thing about vim, you have to actively try to break the normal hotkeys, otherwise everything works. You can use the same keys everywhere to navigate around in any plugin (unless they override them).
> You can do that in any editor. Now lets say you want to open two more files D and E and have them split side by side. In vim, you can make a new tab and create that layout and then quickly switch between A/B/C & D/E. You cannot do that in VSCode or JetBrains. If you're in section B and open a new file, it will make tab inside section B.
Ah, I see yes. VSCode doesn't have nice buffers.
> When I'm using those editors, I find myself constantly creating and destroying layouts and it drives me insane. Let's say I'm editing some files and want to look at the diff of what I've done so far, in vim I can open a new tab and have diff|original.
How do you open the original file ? When I open the file again I end up with both buffers with the same modified content.
> In VSCode it will open the diff in one of my splits, and since it's a diff, it will be split in 2 as well. On my laptop I can't see anything if my diff|original only takes up half my screen, I have to resize/close splits at that point and then going back to what I was doing is more difficult.
Ah yes, when I stumbled into vscode git diff mode I get narrow panes lit up like a christmas tree. I do my git diffing in the terminal or in git-cola or whatever then.
> When I'm working on code and writing tests, I'll usually have my tests in one tab and the code in another. Or if someone asks me a question, I can make a new tab, start searching/reading code in there and then quickly go back to where I went. I find it extremely handy for context switching.
I usually end up with two instances of code running: one for backend/model/controller and the other for the views.
Ah, I see yes. VSCode doesn't have nice buffers.
> When I'm using those editors, I find myself constantly creating and destroying layouts and it drives me insane. Let's say I'm editing some files and want to look at the diff of what I've done so far, in vim I can open a new tab and have diff|original.
How do you open the original file ? When I open the file again I end up with both buffers with the same modified content.
> In VSCode it will open the diff in one of my splits, and since it's a diff, it will be split in 2 as well. On my laptop I can't see anything if my diff|original only takes up half my screen, I have to resize/close splits at that point and then going back to what I was doing is more difficult.
Ah yes, when I stumbled into vscode git diff mode I get narrow panes lit up like a christmas tree. I do my git diffing in the terminal or in git-cola or whatever then.
> When I'm working on code and writing tests, I'll usually have my tests in one tab and the code in another. Or if someone asks me a question, I can make a new tab, start searching/reading code in there and then quickly go back to where I went. I find it extremely handy for context switching.
I usually end up with two instances of code running: one for backend/model/controller and the other for the views.
> In terms of strain, do you not feel strain moving your hand to the arrow keys every time you do those operations?
This is an interesting question - I don't consciously think about it, so I just tried typing with that in mind. I kinda treat the arrows as my normal mode, hopping around until I find what I want to edit, then adjust my position to start writing. So in my mind it doesn't feel like more of an interruption than switching modes. Also, when I shift position, I shift at the elbow, so my wrists are always parallel with my forearms and I prevent strain.
This is an interesting question - I don't consciously think about it, so I just tried typing with that in mind. I kinda treat the arrows as my normal mode, hopping around until I find what I want to edit, then adjust my position to start writing. So in my mind it doesn't feel like more of an interruption than switching modes. Also, when I shift position, I shift at the elbow, so my wrists are always parallel with my forearms and I prevent strain.
If you're not a Vim person yet and not super invested in learning Vim keybinds specifically, may I recommend Helix?
Helix has much better default keybinds, it has a lot of stuff built into it which would require extensions in Vim, and it has a much smoother learning curve (partially due to better keybinds, and partially due to the fact that it will show you which options exist when you eg. press `g`).
As an example: Moving to the start or end of a line is just `gh` and `gl`, which makes a lot more sense than Vim's keybinds. It's still going to take a while to get used to modal editing, but if you don't care about learning vim specifically, then I think that it's an improvement in every single regard.
My personal favorite feature is the multi-cursor editing, especially when coupled with the `s` key.
Helix has much better default keybinds, it has a lot of stuff built into it which would require extensions in Vim, and it has a much smoother learning curve (partially due to better keybinds, and partially due to the fact that it will show you which options exist when you eg. press `g`).
As an example: Moving to the start or end of a line is just `gh` and `gl`, which makes a lot more sense than Vim's keybinds. It's still going to take a while to get used to modal editing, but if you don't care about learning vim specifically, then I think that it's an improvement in every single regard.
My personal favorite feature is the multi-cursor editing, especially when coupled with the `s` key.
I'll give Helix a look, thanks for the recommendation.
Tips:
- bind going back to normal mode to something other than Esc. Popular ones are capslock, Ctrl-[, jj, and jk
- use forward/back by word (w, e, and b) rather than going by character. Add numeric prefixes for faster jumping, eg jump to end of 3rd word with 3e
- turn on relative line numbers and use prefixes to jump to the desired line, eg 10j to go down ten lines, copy lines (y10j), etc.
- use f to go forward to a desired character, eg fk to go to the next k
- use i to apply actions to whatever is inside of brackets/parens/etc. Eg delete everything inside of parens with di), copy everything inside of braces with yi}
- I don’t remember if you have to turn it on specifically, but the vim mode for vscode supports vim surround, so you can do stuff like: change surrounding single quotes to double quotes with cs’”, add double quotes to word with yse”, etc
- bind going back to normal mode to something other than Esc. Popular ones are capslock, Ctrl-[, jj, and jk
- use forward/back by word (w, e, and b) rather than going by character. Add numeric prefixes for faster jumping, eg jump to end of 3rd word with 3e
- turn on relative line numbers and use prefixes to jump to the desired line, eg 10j to go down ten lines, copy lines (y10j), etc.
- use f to go forward to a desired character, eg fk to go to the next k
- use i to apply actions to whatever is inside of brackets/parens/etc. Eg delete everything inside of parens with di), copy everything inside of braces with yi}
- I don’t remember if you have to turn it on specifically, but the vim mode for vscode supports vim surround, so you can do stuff like: change surrounding single quotes to double quotes with cs’”, add double quotes to word with yse”, etc
Not going to try to evangelize the vi(-clones) way to you, but I would encourage you to let go of what you think you know and just try it for a while.
Think of the difference between vscode and vi as similar to the difference between a game controller vs mouse and keyboard. They are very different ways to do the same thing.
Also, if you don't touch type (fingers on home row) it might not feel immediately better. For me, it made sense pretty quickly because it was clear the goal was to move as little as possible away from where my fingers rest.
The other thing to note is that there is a depth to vim's feature set you will not find in most software, so when people rave, they may be raving about different parts you haven't discovered yet.
Think of the difference between vscode and vi as similar to the difference between a game controller vs mouse and keyboard. They are very different ways to do the same thing.
Also, if you don't touch type (fingers on home row) it might not feel immediately better. For me, it made sense pretty quickly because it was clear the goal was to move as little as possible away from where my fingers rest.
The other thing to note is that there is a depth to vim's feature set you will not find in most software, so when people rave, they may be raving about different parts you haven't discovered yet.
Also one of the things I love about vscode is that it has a great extension that embeds neovim.
As I mentioned above, vim is about the interaction style mostly. With the embedded plugin I can leverage vscode extensions and vim's interaction model.
As I mentioned above, vim is about the interaction style mostly. With the embedded plugin I can leverage vscode extensions and vim's interaction model.
> By contrast, in Vim you use $ to move to end of line, and ^ to move to begin of line. Not only is it unintuitive, it requires more strain of my hands/fingers
It is intuitive if you use regular expressions too because ^ and $ have (nearly) the same meaning there. But you’re right that your shortcuts work well too.
Other shortcuts that come in useful with no non-Vim equivalent that I know of:
It is intuitive if you use regular expressions too because ^ and $ have (nearly) the same meaning there. But you’re right that your shortcuts work well too.
Other shortcuts that come in useful with no non-Vim equivalent that I know of:
vi" to select the content of a string
ca" to change a string
va{y to select and copy (“yank”) the contents of a curly-brace block
} to move one paragraph forward
) to move one sentence forward
v) to select the next sentenceIt is intuitive if you find regular expressions intuitive.
Note that it's not the only way to go to the end of line.
Home/End bring you to beginning/end of line like anywhere.
`I` is like `^` followed by `i`, brings you before the first non-empty char in insert mode.
`A` is like `$` followed by `a`, brings you after the last char in the line in insert mode (append).
If you'd like to select things press `v` in normal mode and move around with directions or Home/End or ^/$.
All things considered there are only so many keys to have meaningful/semantic shortcuts, you get used to the one you use the most.
Note that it's not the only way to go to the end of line.
Home/End bring you to beginning/end of line like anywhere.
`I` is like `^` followed by `i`, brings you before the first non-empty char in insert mode.
`A` is like `$` followed by `a`, brings you after the last char in the line in insert mode (append).
If you'd like to select things press `v` in normal mode and move around with directions or Home/End or ^/$.
All things considered there are only so many keys to have meaningful/semantic shortcuts, you get used to the one you use the most.
You probably don't use $ and ^ to move around in a line. It's much more likely you want to add text at those locations, so you'd use A to append to the line or I to insert at the start of the line. These are much easier to type. Similarly, gg and G are beginning and end of file, and V selects the entire line, but you could use c^ or c$ if you do actually want to change to the beginning or end of the line.
[deleted]
Of course the bindings you create are inherently going to be more intuitive to you, but Vim bindings are designed so you can do all the editing you need without moving your hands (like moving your hand over to the arrow keys).
> By contrast, in Vim you use $ to move to end of line, and ^ to move to begin of line. Not only is it unintuitive
Actually it's very intuitive, because ^ and $ mean start/end of line in regex.
Actually it's very intuitive, because ^ and $ mean start/end of line in regex.
On a similar note: the P and V semaphore operation names are very intuitive, because passering means "pass" and vrijgave means "release" in Dutch, as clearly noted by Edsger Dijkstra.
> By contrast, in Vim you use $ to move to end of line, and ^ to move to begin of line.
You can also use shift+i and shift+a to move o beggining/end of line and enter insert mode.
You can also use shift+i and shift+a to move o beggining/end of line and enter insert mode.
if typing dollar and caret signs strain your fingers it means that you aren’t using the opposite hand to press shift.
one-handing two keys will hurt your hands in the long run.
one-handing two keys will hurt your hands in the long run.
Also usable in less(1), for those who don’t usually run vim/vi, but often run less(1).
I love Vim and use it (and Vim modes in IDEs frequently), but this isn't exclusive to Vim.
Alt-Left in Eclipse and Intellij will move back through recent positions, and Alt-Right moves forwards. Though I think it's different between the two out of the box. (I use Eclipse keybinds in Intellij)
Alt-Left in Eclipse and Intellij will move back through recent positions, and Alt-Right moves forwards. Though I think it's different between the two out of the box. (I use Eclipse keybinds in Intellij)
[deleted]
:h jumplist
:h jump-motions
Not to "recent line". To "line before latest jump".
This is in section 10 of chapter 3 of the :help user-manual. That's like… day 1 material. Not worthy of HN, IMO.
This is in section 10 of chapter 3 of the :help user-manual. That's like… day 1 material. Not worthy of HN, IMO.
> This is in section 10 of chapter 3 of the :help user-manual. That's like… day 1 material. Not worthy of HN, IMO.
I assure you, nobody makes it to chapter 3 of the manual on day 1. Not to mention that the manual is long enough that most people don't seriously read it (much like bash: Yes, the manpage documents it well, but there's too much material to expect everyone to go through it all)
I assure you, nobody makes it to chapter 3 of the manual on day 1. Not to mention that the manual is long enough that most people don't seriously read it (much like bash: Yes, the manpage documents it well, but there's too much material to expect everyone to go through it all)
been using vim for 10 years, I didn't know this, and it's on the frontpage of HN, that would make it worthy, IMO
Maybe it's not too late to start learning it properly instead of relying on random posts.
There is a manual? I thought vim was tough through verbal anecdotes from generation to generation
The bundled manual is really good.
vim
:help
:only
Jump to subject: Control-]
Jump back: Control-oIsn't <Ctrl-o> more useful in general?
Cool, i guess
(It's two single-quotes, not a double quote.)