Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intermediate Vim tips

kinbiko.com

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Intermediate Vim tips

#71

Post by semi-extrinsic »

burntsushi wrote: post #70
semi-extrinsic wrote: post #66

Earlier quoted context omitted.

I don't get the 80 char limit at all. But then my display is 43" at 3810 pixels horizontally, so at my normal font size I would be able to fit, what, 7 or 8 windows side by side at 80 columns wide?

What don't you get about it? I can understand you having a different preference. That's normal, we all like different things. But not getting it at all? That's just weird. I'll explain why for me. On my 24" 1920x1200 monitor, I want to be able comfortably fit two editor windows side-by-side where neither window auto-wraps the code. 79 columns works well for that. This is a function of my ability to read the text, whi…

I suppose I phrased it badly - I meant I don't get why anyone would have a limit as low as 80 unless they're coding on an Apple II or a 10" netbook. But you fill your 24" 1920x1080 with 160 characters and change? That's like font size 18, just sounds huge to me. But hey, it's your display.

Also, I do quite a lot of numerical code where it's more important to me to line stuff up so that physical symmetries are reflected in the code, makes coding much easier and less bug prone. So I guess that also explains my bias.

But like you say, we all like different things.

Re: Intermediate Vim tips

#72

Post by ssivark »

vinceguidry wrote: post #37
lunchables wrote: post #30

Earlier quoted context omitted.

Most people store their dot files (including their vim config) in a git repo and just check out a copy on any machine they use. That's what I do (git+stow). I can be up and running on a new system in just a few seconds.

Does anybody know a saner way of doing this cross-platform? I've resorted to doing platform checks in my .bashrc and don't get me started on the OSX / Linux differences in .platform, .bash_platform, and .bashrc sourcing. And when I tried termux on Android, oh dear lord. The whole thing breaks because of permissions issues. Had that issue on WSL too.

Across linux and OS X, I use a solution based on the this HN comment and it's follow-up discussion: https://news.ycombinator.com/item?id=11071754

Lot of other suggestions on the same HN thread: https://news.ycombinator.com/item?id=11070797

Re: Intermediate Vim tips

#73

Post by minitech »

u801e wrote: post #59
minitech wrote: post #29

Earlier quoted context omitted.

I break lines if it looks like they’re getting too long, where it feels right to do so. Setting a fixed number of columns causes people to align hanging lines to the right in my experience: some_example_code = LongTypeName(argument_one=1, argument_two=2, argument_three=3) (pretend that’s 80 columns), resulting in this mess when I try to look at it in a narrower view: some_example_code = LongTypeName(argument_on ↳ e=1…

> What does help is creating indented blocks where it feels right Over the years, I've come to believe that using a hanging indent for alignment is actually better in terms of readability as opposed to aligning at a column after the opening parenthesis, brace, or bracket. It's also easier to type as well even if the editor doesn't provide an auto-indent facility (or if it's not configured correctly for some reason) s…

> Over the years, I've come to believe that using a hanging indent for alignment is actually better in terms of readability as opposed to aligning at a column after the opening parenthesis, brace, or bracket. It's also easier to type as well even if the editor doesn't provide an auto-indent facility (or if it's not configured correctly for some reason) since you only have to press TAB the same number of times to correctly position each formal parameter in the function definition.

> As a side benefit, it also takes care of any alignment issues regardless of whether one uses tabs or spaces.

That’s exactly what I said.

> Another benefit of doing this is that it makes a unified diff and side-by-side diffs easier to read.

Until you rewrap and it adds noise to the diff. I recommend a combined word/line diff instead.

Concatenation also hides whitespace problems. Not a serious error, but a very common one.

  "This ends with a period." +
  "But this doesn’t start with a space."

Re: Intermediate Vim tips

#75

Post by mythrwy »

brian-armstrong wrote: post #51
mythrwy wrote: post #28

Earlier quoted context omitted.

LOL that was my exact thought. Added to .vimrc. But will never get back all the time lost trying to make sure I was at proper indent level.

I highly highly recommend always using a linter/formatter that just fixes this for you

Python. Indention matters. Unless there is a linter that can tell intent (and maybe there is on that offers an option?) indention can be the difference between once and forever.

Re: Intermediate Vim tips

#76

Post by mcmatterson »

unknown_apostle wrote: post #52
i_feel_great wrote: post #2

Where have you been all my life, "set cursorcolumn"?

Is it me, or does cursorcolumn really give Vim a bit of a sluggish feel?

It's not just you. I noticed it a few months ago and ended up disabling cursorline entirely. It seems to be caused by an intersection of cursorline and specific syntax highlighting rules (it happens for me in Elixir, but not in Ruby, for example). Honestly, while line highlighting is nice, I can't be bothered figuring out the way through it.

https://www.reddit.com/r/vim/comments/6onaui/vim_getting_slo...

is at least one exploration.

Re: Intermediate Vim tips

#77

Post by jdblair »

MikkoFinell wrote: post #47
jdblair wrote: post #21

Earlier quoted context omitted.

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…

The row and column limit is more of a guideline, not a hard and fast rule.

Re: Intermediate Vim tips

#78

Post by hitripley »

ekianjo wrote: post #65
hitripley wrote: post #42

Earlier quoted context omitted.

CtrlP is much slower when indexing large directories.

When you say large, how large is that?

I have a directory with about 40,000 java files. It takes 11 seconds for ctrlp to finish indexing (without using cache). Fzf finished it before I start counting.

Re: Intermediate Vim tips

#79

Post by macrael »

MikkoFinell wrote: post #44
macrael wrote: 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.

Does anyone have rules that take into account indentation? I suppose too much indentation is its own issue, but seems like 80 could be flexible with your indentation.
Post reply on HN