Hacker News Reader

Comment by strogonoff | Hacker News Reader

Why not one line?

    set hls ic is nu noswf

On a serious note, personally disabling line numbers is the first thing I do in a new editor. Reduces visual noise—status line usually shows current line number anyway, jumping to a line might take a second and I found I don’t need to know my line numbers more frequently than once per month or so.

What I do like to enable in an editor is visible whitespace characters (helps notice levels of indent, for example). In Vim that can be accomplished with:

    set list listchars+=space:•

(Might take some tweaking to make whitespace appear subtly enough, depending on your color scheme.)

View on HN

Interesting. The first thing I always do in a new is enable the line numbers. I pair-program a lot and find them to be invaluable when talking about the code.

I can see how line numbers would be immensely useful if I ever pair program remotely.

Line number are super helpful for navigating in vim, though. :54 when you’re on line 20 is much faster than any alternative.

Some folk like `34d` so they don't need to press shift. And sometimes set relative line numbers so they don't need to do the subtraction.

Others just search for known text, which IMO is a habit I need to get into. I "got" hjkl after I disabled the cursor keys for a day, but I never followed up and disabled hjkl (or maybe even w and b!?) to get super efficient.

I have never considered disabling hjkl, quite an interesting idea.

You can just use 54gg, no shift involved.

I often navigate with the search. It's fast as I usually know where I want to go.

Also with the right setting(I think incsearch) Vim immediately jumps to the first result as you type, so I often use search to quickly peek at some code and then jump back with Esc when it doesn't warrant splitting the buffer.

But I do still struggle a bit with moving within the line - w and b tend to "get caught" in long series of different symbol categories that Vim will all see as separate words/tokens. At least I got my setup with the "camelcasemotion" plugin working, which is a great help with long identifier names.

I see, I suppose it depends on one’s habits then. Personally I’m used to roughly approximating relative jumps or using search to arrive at the desired identifier, but then I wouldn’t call myself especially efficient.

The only time I find using :number is when I am exploring a codebase elsewhere, e.g. using GitHub’s web interface, and want to jump to a particular line in Vim to make edits—rarely happens.

I would type "8j8j8j8jjj". I type "8j" (and "8k") a lot.

I bind those commands to "shift-j" and "shift-k" and heavily abuse them.

It's not pretty, one could argue that the mouse is more efficient for such movements, but for me it's faster in practice than moving my hand to the mouse/trackpad, or than looking up a line number (either absolute or relative) and then typing it. And it has no mental burden.

I usually go with { and } for those to jump between paragraphs, as that is usually a sensible distance of movement. But your approach is also an interesting addition as it's more consistent.

I use them heavily. Also, check out ]] [[ and ]m (jump to end of function).

I use H, M, L to move the cursor to the top, middle and bottom of the screen, and ctrl-f and ctr-b to scroll half a page, which drags the cursor along for the ride if it would otherwise be offscreen.

Thanks, I didn't know about putting everything on one line. I've updated the post to include this tip.

As for showing line numbers, I'm often doing this to read logs on a remote VM. In those scenarios, having easy access to where you are in the file is really helpful.

For spaces, I have:

    set listchars=tab:>-

    set listchars+=trail:⋄

This shows markers for tabs and trailing whitespaces.

The latter will make you very sad when you browse other people's code.

Funny you say that about the visual noise because as someone who’s dyslexic, I find line numbers actually help with readability since it is easier for me to remember a number than it is text.

I also find it especially useful in vi when working with config files. I’m sure you are aware of this feature but in case others aren’t, in vi if you type numbers before a command, it runs that commend n times. So you can quickly copy or delete multiple lines.

It just goes to show how deeply personal a preference a persons code editor is.

Indeed, to your last sentence.

I use shift+v and a j/k relative jump to select a range of lines, then do the operation. Which is undeniably the slower way.

Didn’t know how dyslexia affects this, I will keep that in mind in case I happen to work with someone with it.

    set list listchars+=space:•

This adds a lot of clutter! It's better to show only indentations (of course, using tabs):

    set listchars=tab:├─

Line numbers are great, until you try to cut and paste. But then again, VI/M wasn't designed for GUIs.

I don’t copy and paste, I just don’t see the need for line numbers. But then I also code with syntax highlighting off about half of the time.

Very interesting, I don't think I've ever talked to someone who would choose to disable syntax highlighting. Do the colors actively annoy you or is it just that you don't care?

I find that not having highlighting to rely on forces me to write more readable code. I might turn it on if I happen to work on a hairy codebase under time constraints.

Sometimes also colors in general can get distracting and I just turn on grayscale system-wide, which also doesn’t play with syntax highlighting as text ends up being varying shades of gray with not enough contrast against the background.

I grew up without it and I think my brain is wired to recognize visual structure instead of colors.

Switching it off is the first I do.

I tried both ends of the spectrum.

There’s definitely something real about too much colours; the archetypal example of colouring our human language tokens by type (verbs, nouns, etc) making no sense sure rings home after a while.

But I found very much use of “colour”+ themeing for two things:

- comments vs code, one toned down vs the other, ideally swappable with a hotkey

- delimited content such as strings. It sure saves a lot of time when you get an imbalanced delimiter nested in a forest and the whole of your file changes colour starting near the imbalance.

I’m very much of the opinion that a lot of syntax highlighting is just dumbed down token matching and badly designed (if at all designed), when it should be much smarter in alerting you of inconsistencies, and putting relevant content forward.

+ by colour I don’t necessarily mean literally in colour, bold or italics can serve well.

I have seen some C code so heavily #ifdef'ed that toning down the parts that are excluded in the current build would be helpful.

I am looking forward to smart highlighting that does what you say (marking errors and inconsistencies, like perhaps a truthiness check being used with a variable that could be both null and undefined in case of a typed language) and otherwise is based on context (for example, highlighting a variable that was defined in outer scope is something that could be legitimately useful).

Colouring human language by tokens is a very fitting analogy.

Count me as another. I find syntax highlighting to be distracting unless it is done with some restraint (which it rarely is), and not helpful enough for me to bother with coming up with my own scheme or searching for one that I like.

I am sure there are corner-cases where I would want to enable it, such as were someone has been in the habit of commenting-out parts of a line.

I don't know anyone who uses syntax highlighting for natural-language prose, though I suppose there are some who do.

Yay im not alone!

I've always found syntax highlighting super distracting, but everyone i have met thinks im crazy.

Otoh i do love me line numbers.

> But then I also code with syntax highlighting off about half of the time.

Wow, don't ever use VSCode then! There are hovering diacritics and proofing marks everywhere!

It does real-time syntax checking and quick compilation to check interfaces (at least with TypeScript, JS, HTML, pug, css, Vue, and NodeJS).

I resisted fancy editors for years, as I found them crazy annoying, but over the past few months I've grown to adore VSCode because it has made me about 50% more efficient: I don't have to run the app to find errors, the IDE finds them for me, and it works on Win10, macOS and Linux. It is extremely context aware of my project.

It's like JetBrains but free (or Android Developer Studio, also made by JetBrains...).

I actually use VSC in Vim mode for TypeScript work as I couldn’t get Vim to nicely show verbose deeply nested typing hints (maybe someone knows a way?). There is a “mono white” theme, it still shades a few keywords in grey but otherwise is pretty good.

Hah, I'm the exact opposite. Greatly enjoy very colored themes, but it feels like almost all themes are about 50% white text with only a handful of things colored.

I set F12 to toggle line numbers off/on. Very quick and handy.

:nmap <F12> :set invnumber<CR>

I have the default register mapped to the system clipboard so doing yank in vim I can paste into anywhere else - no need to use the mouse or worry about line numbers

    " mac clipboard {{
    if has("clipboard")
      set clipboard=unnamed
    endif
    " }} mac clipboard

If your vim is compiled with the correct flag for GUI operations (I forget which), you can yank/delete text into the * or + registers to make it available to the system clipboards. This won't bring the line numbers, and lets you avoid using the mouse.

I think it's just called +clipboard. And with the setting "set clipboard=unnamedplus" Vim will use the system clipboard for yank, delete and paste by default.

I use vim in a terminal, the way the gods intended, not gvim. ;-P

But apparently according to peer comments, there are ways to yank into clipboards, which is pretty cool.

Not only that but if you set your mouse up correctly then you can use the mouse for selections and have it respect window splits too.

That works in tmux too. So you can have use the terminal but have it behave as a GUI app in most respects. For example being able to use a touchpad to quicly enlarge/resize splits or scroll a window can be quite useful.

This works with standard vim in a terminal as well. I too follow the old gods.

Reply on news.ycombinator.com