Comment by rendall | Hacker News Reader

Comment by rendall | Hacker News Reader

Great job on this!

> what is all this need for complicated editing features? Why does a text editor require programming capabilities? Why is there even a requirement to learn how to use a text editor? Isn't it enough to have the ability to enter text, use Backspace/Delete/Home/End/Arrow/etc, menu and toolbar, some shortcuts, a search and replace feature and so on? A simple and short answer — to reduce repetitive manual task.

For me, the entry way, what convinced me to try Vim, was the advantage of not needing to move the mouse. That back and forth movement - lifting my hand, grasping for the mouse, moving the cursor to where it needs to be, clicking and dragging to highlight text, ctrl-x, moving the cursor to where it needs to be, ctrl-v, repeated throughout the day just felt inefficient.

But what really makes it feel like a super power is the repetitive tasks thing. Convert hundreds of dates from dd.mm.yyyy to ISO 8601? No problem! Alphabetize those lines? Can do. Convert that Jira ticket title to a git branch name? It's done already.

But "repetitive tasks" would never have convinced me to try it. "Just use cut and paste", I would have countered.

What finally made me switch was not seeing people editing with vim, but rather how they moved around and navigated, which seemed so much faster than any other editor.

What's the best way to rapidly move around without having to count lines? I sometimes use Ctrl + U and Ctrl + D to move entire pages but always found it a bit more laborious to move around in Vim. 13j seems like it would require me to count exactly 13 lines before I can get there.

I use vim + mouse unfortunately because it is quicker unless there is a better way?

#G (i.e. 20G) would put the cursor on line 20, but that's only useful if you have line numbers in your editor. If you have relative line numbers then #j movement is easy since the number you need to jump up or down should already be calculated.

I did turn on relative line numbers and still feels laborious compared to mouse click which happens within 500 ms.

Say I want to go up by 13 lines and on the 4th word:

Step 1: Scan visually on the left gutter for a line number (relative or not)

Step 2: 13j

Step 3: 3e (3 words to the right)

Everything else in vim is fast except navigation for me. With mouse, it is a little bit of a pain to move the hand over to the mouse and the click, but still feels orders of magintude faster than jumbling around with line numbers.

I mostly use / and ? for jumping about in the code. It’s always just a few keystrokes and you’re where you want to be.

I use { } to move by paragraph/block quite a bit.

/ or ? to search forward or backward.

C-f and c-b to go a full page. U and d are half.

But for me it’s not only about speed. I guess it just feels nice to use the keyboard, even when it’s a little slower.

When I open a file, I fold everything (zM) to get an overview of the file. Then I slowly unfold as I'm browsing, ignoring the parts I don't care about. I set the repeat delay super low and repeat rate super high on my keyboard and just navigate around by holding j/k or {/} (for large folds). Since everything is folded, you're moving about pretty quickly.

If you're looking to use the 20j stuff, you can `:set relativenumber` so that vim shows you line numbers relative to the selected line to avoid counting. I couldn't get used to it.

There's also Hop[0] if you want to go the plugin route.

[0] https://github.com/phaazon/hop.nvim

I've always wanted a sort of "hybrid" line numbering scheme. Show me the relative numbers in one column, and the absolute line numbers in another column. You can set up vim so that the absolute number appears on the line your cursor is on (and the other lines display relative nums) but this isn't quite enough.

I want both, dammit!

There is Lightspeed, which is a buffer search tool thing, bound to `s`.

It's pretty nice, but to be honest I just use `/` and `n` a hell of a lot. And `j` is probably my most used character. :)

> What's the best way to rapidly move around without having to count lines?

oooh. I have a treat for you! Check out "hybrid line numbers". I thought they would be weird when I heard about them, but they're awesome, and I never need "absolute line numbers". But the linked article shows you how to set up toggling if you need them.

Basically, they look like this:

  3 Lorem ipsum dolor sit amet, 
  2 nunc in iaculis ipsum.
  1 Suspendisse dapibus odio erat,
 98 non varius nulla porttitor at. // <-- You are here
  1 Nullam in convallis elit.
  2 Sed nec venenatis ligula.
  3 consectetur adipiscing elit. 
  4 Sed hendrerit ac ante sed viverra.

In this example, your cursor is at line 98 and so shows the absolute line number. The other lines are relative to your current line. If you want to go down to the line that starts consectetur, you see that it is below you 3 lines. You have to type 3j. If you need to find a specific line number, say 24, type :24

Here's an article on them: https://jeffkreeftmeijer.com/vim-number/

I used to use this method until I tried out easymotion, which really does live up to its name.

https://github.com/easymotion/vim-easymotion

A lot of the time, you want to be using a more meaningful (as in semantic) command like } or ]] or / - my Vim navigation improved a lot once I started understanding / as a navigation command i.e. a "go where I know this text is" rather than just "find where this text is".

But when you do need to move by lines, `set relativenumber` is very helpful. I have both `set number` and `set relativenumber` in my Vimrc, so I get relative numbers for all other lines except the current one. For the current line, the absolute line number in the file is displayed (which is more useful than the relative "0").

> A lot of the time, you want to be using a more meaningful (as in semantic) command like...

I try never to second guess why someone wants to know something, and if I answer at all, to answer the direct question. Otherwise it might come off as patronizing and gate-keeping.

As an asker, I'm much more open to hearing the answer to an unasked question when I have the answer to my asked question.

My least-favorite genre of dev answer is Q: "How do I X?" A: "Don't X. Y instead."

Also, part of the awesomeness of Vim is that it's personal, how someone uses it. If information is structured in lines in someone's mind, and it makes more sense for them to navigate that way, they aren't doing it wrong.

I use: H move to the to of the current view M move to the middle of the current view L move to the bottom of the current view

The way I remember them is (H)igh, (M)iddle, (L)ow

Also setting fold to indent and collapsing the whole file with zM is super helpful for navigating large files.

Lastly I use searching a lot with / or ? To just type the pattern I'm looking for # to search for the word under my cursor.

> What's the best way to rapidly move around without having to count lines?

Don't? Just turn on line numbers with `set nu`. Add it to your `.vimrc` for a default. In a pinch where you need to copy/paste graphically in your terminal and don't want the line numbers on? `set nonu` to turn them off again.

Sibling comments also have great solutions/different ways of navigating.

I just press and hold j until i'm on the line i want to be on if it's that close.

otherwise ctrl-f and u coupled with zz to center it

gd for go to definition.

using { and } for paragraph navigation is also useful. / is nice for words you know coupled with n and N

and using something like an outline is also nice to use when visually selecting.(i've been using neovim as a backend for vscode so this is built in) and if you use vscode they have a nice go back out feature too ctrl + - (which i forget what it is in vim but probably gb if i had to guess but you are limited to how vim works in that regard.

I find using marks along with the associated jumplist (ctrl-o and ctrl-i) and changelist (g; and g.) commands very useful.

If you're willing to use a plugin: easymotion (or, for nvim, hop.nvim)

Reply on news.ycombinator.com