Tell HN: '' in Vim moves cursor to recent line

[surprisetalk]

  '' Recent line

  `` Recent line and column

(It's two single-quotes, not a double quote.)

[linsomniac]

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.

[hirundo]

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?

[jstimpfle]

'<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

[kps]

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.

[navan]

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;.

[jstimpfle]

I've always done "undo-redo" which achieves the same, but I guess ; could be used for other purposes.

[n8henrie]

g; and gv are the two that keep me from using helix more.

[y7]

Also Ctrl-O for back, and Ctrl-I for forward, are useful.

And '. for line of the most recent change in the current buffer.

[sja]

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/

[k0k0r0]

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.

[danielvaughn]

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:

  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

There are several others but they're all similar in that they feel logical and intuitive.

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?

[messe]

> 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).

[hexfish]

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.

[masukomi]

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.

[reg_dunlop]

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.

[otterpro]

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.

[johnchristopher]

> 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).

[doix]

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...

[TwentyPosts]

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.

[mplanchard]

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

[gorjusborg]

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.

[nequo]

> 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:

  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 sentence

[ndr]

It 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.

[CGamesPlay]

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.

[numboreal]

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).

[olddustytrail]

> 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.

[guilherme-puida]

> 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.

[kobalsky]

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.

[teddyh]

Also usable in less(1), for those who don’t usually run vim/vi, but often run less(1).

[Bjartr]

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)

[tambourine_man]

  :h jumplist
  :h jump-motions

"gi" is also useful.

[johncoltrane]

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.

[yjftsjthsd-h]

> 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)

[armonge]

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

[number6]

There is a manual? I thought vim was tough through verbal anecdotes from generation to generation

[rane]

Isn't <Ctrl-o> more useful in general?

[crickey]

Cool, i guess

[trollied]

How to quit it, just in case you're unsure:

:q!

[YeGoblynQueenne]

?