Live data from Hacker News

Intermediate Vim tips

kinbiko.com

41–50 of 79 posts

Re: Intermediate Vim tips

#41

I’m probably the minority here but I don’t like to customize my Vim too much. 1 - it takes time. 2 - half the reason I like Vim is because I can use it anywhere. If I’m so used to a highly customized setup, then I am going to feel out of place when I log on somewhere else.

I used to have this mindset, but now that I've got all my dot files on github I can get a machine set up pretty quickly. And for those times where I'm SSHing into a machine for whatever reason, using plain old vi hasn't been a problem. I typically do avoid overriding any of the main key bindings though so that I don't get confused when I do have to use plain vanilla vi.

Re: Intermediate Vim tips

#43
post #17

> I don't like excessively long lines of code (120+ in most languages) Quick straw poll on this... How many people like a line length limit? My personal preference is a fairly strict 80 (barring silly things like URLs), but I've always been met with resistance to ANY line length limit. Is it really that imposing?

After years of Objective-C I don't blink unless a line is over 140 characters. Some things just look better that way.

Ditto for C#. It's otherwise a fine language, but you're already 12 spaces into a line before you write any executable code (assuming tab = 4 spaces). 80 chars per line just doesn't work :-(

Re: Intermediate Vim tips

#44
post #11

> I don't like excessively long lines of code (120+ in most languages) Quick straw poll on this... How many people like a line length limit? My personal preference is a fairly strict 80 (barring silly things like URLs), but I've always been met with resistance to ANY line length limit. Is it really that imposing?

I think line limits are a good idea, though I sort of do them by feel usually. That said, 80 feels incredibly restrictive, a relic of bygone monitor sizes.

It's not just that, in fact the reason for limiting to 80 is mostly because short lines help readability because of how human eyes operate. Eyes prefer to stay within a small circular region located in the center of the visual field. Too much vertical or horizontal movement makes it harder to see, but vertical movement isn't an issue in text because of scroll, but horizontal movement is a problem.

Re: Intermediate Vim tips

#46

Whenever a Vim post mentions grep, ack or ag — especially in conjunction with fzf/fzy — I'll make sure to mention the even faster rg (ripgrep): https://github.com/BurntSushi/ripgrep BurntSushi's write-up about the internal workings of ripgrep is also super interesting: http://blog.burntsushi.net/ripgrep/ ) It's a really amazing piece of software. It has also recently been included in Visual Studio Code to search in f…

I use ripgrep and it's pretty great, but I don't know why Visual Studio Code would be using it. Why not just use Rust's Regex library instead?

Re: Intermediate Vim tips

#47
post #21

> I don't like excessively long lines of code (120+ in most languages) Quick straw poll on this... How many people like a line length limit? My personal preference is a fairly strict 80 (barring silly things like URLs), but I've always been met with resistance to ANY line length limit. Is it really that imposing?

I like an 80 column limit for C and python, but it starts to be a problem in C++. This says something about C++ and I don't think it's positive. I actually also like a fairly small limit on the number of rows (around 40). If my functions and methods are too complex to understand in this much space then it's time to refactor. Of course, I usually have to work on existing code and the functions/methods are not always s…

I've often found that having all the code that's doing one thing in the same place is better than splitting it up into a bunch of functions just to keep rowcount low. It makes it easier to step through and reason about what is going on if all the steps of a logical sequence are actually laid out in a sequence (instead of intermittently jumping to other files). Whenever I find a function that I discover is only called in one place I just inline it, and in my opinion that improves the code every time. Abstraction is important, but understandability is more important.

Re: Intermediate Vim tips

#48
post #46

Whenever a Vim post mentions grep, ack or ag — especially in conjunction with fzf/fzy — I'll make sure to mention the even faster rg (ripgrep): https://github.com/BurntSushi/ripgrep BurntSushi's write-up about the internal workings of ripgrep is also super interesting: http://blog.burntsushi.net/ripgrep/ ) It's a really amazing piece of software. It has also recently been included in Visual Studio Code to search in f…

I use ripgrep and it's pretty great, but I don't know why Visual Studio Code would be using it. Why not just use Rust's Regex library instead?

Is it? Funny because I have tmux open in the side pane, and execute my searches that way.

Re: Intermediate Vim tips

#50
post #11

Earlier quoted context omitted.

I think line limits are a good idea, though I sort of do them by feel usually. That said, 80 feels incredibly restrictive, a relic of bygone monitor sizes.

It's not just that, in fact the reason for limiting to 80 is mostly because short lines help readability because of how human eyes operate. Eyes prefer to stay within a small circular region located in the center of the visual field. Too much vertical or horizontal movement makes it harder to see, but vertical movement isn't an issue in text because of scroll, but horizontal movement is a problem.

Yes; see https://en.wikipedia.org/wiki/Line_length
Post reply on HN