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.)
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.
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 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 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.
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 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.
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.
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.
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.
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.
> 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.
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?
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 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.
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.
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.
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:
(Might take some tweaking to make whitespace appear subtly enough, depending on your color scheme.)