Intermediate Vim tips (opens in new tab)

> 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) 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.

> and letting other lines just naturally be long.

Using the language's feature for string concatenation still makes it as easy to read:

  some_example_code = LongTypeName(
        "just a string that happens to be long; some people introduce " +
        "acceptable percentages of string literals for long lines, but it's " +
        "really not necessary. let word wrap take care of it!")

Another benefit of doing this is that it makes a unified diff and side-by-side diffs easier to read. Contrast the wrapped version when I add another sentence to the end of your example:

  diff --git a/tmp/wrapped b/tmp/wrapped
  index 972537b..27e3e31 100644
  --- a/tmp/wrapped
  +++ b/tmp/wrapped
  @@ -1,4 +1,5 @@
     some_example_code = LongTypeName(
           "just a string that happens to be long; some people introduce " +
           "acceptable percentages of string literals for long lines, but it's " +
  -        "really not necessary. let word wrap take care of it!")
  +        "really not necessary. let word wrap take care of it! Though unified " +
  +        "and side-by-side diffs may be more difficult to read")

versus the unwrapped one:

  diff --git a/tmp/unwrapped b/tmp/unwrapped
  index 284ef1e..db47f46 100644
  --- a/tmp/unwrapped
  +++ b/tmp/unwrapped
  @@ -1,2 +1,2 @@
     some_example_code = LongTypeName(
  -      "just a string that happens to be long; some people introduce acceptable percentages of string literals for long lines, but it's really not necessary.  let word wrap take care of it!")
  +      "just a string that happens to be long; some people introduce acceptable percentages of string literals for long lines, but it's really not necessary.  let word wrap take care of it! Though unified and side-by-side diffs may be more difficult to read")

With the wrapped version, you can more easily see what I added to the end of the line in your example. In the unwrapped example, I most likely would have to either scroll horizontally to read the entire line. If the line is soft-wrapped, then I would have to realize that the second line is part of the previous line and not a different context line (soft-wrapping is simulated by hard-wrapping right after the "for long lines," comma and the space after "difficult to " based on how blockquoted text appears a rendered comment):

  diff --git a/tmp/unwrapped b/tmp/unwrapped
  index 284ef1e..db47f46 100644
  --- a/tmp/unwrapped
  +++ b/tmp/unwrapped_more
  @@ -1,2 +1,2 @@
     some_example_code = LongTypeName(
  -      "just a string that happens to be long; some people introduce acceptable percentages of string literals for long lines,
  but it's really not necessary.  let word wrap take care of it!")
  +      "just a string that happens to be long; some people introduce acceptable percentages of string literals for long lines,
  but it's really not necessary.  let word wrap take care of it! Though unified and side-by-side diffs may be more difficult to
  read")

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?

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.

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.

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 :-(

I wish I could upvote your comment many times. I wish the parent comment pointed out what use case they have for Vim, as this really dictates the "right" approach.

I wrote about this previously in the context of Vim vs Emacs, though it's similar to customized vimrc/plugins vs vanilla vimrc:

"One can reduce part of the [editor] debate down to a single question: how fully featured do you want your text editor out of the box? If you’re a DevOps engineer who spins up new environments constantly you’ll have different ideas about the best choice compared to a full stack engineer working in a single development environment that can be painstakingly setup. For the DevOps engineer, a light text editor that is installed by default is likely ideal, while for a developer with a single computer, a full-featured IDE (auto-completion, plug-ins, custom keys) is worth the high setup cost."

https://www.nemil.com/musings/betterdebates.html

> it’s crazy that you’d leave tons of productivity enhancements on the table because you want that standardized, bottom-of-the-barrel experience

Like what exactly and compared to what environment?

You can remotely edit on any system accessible over ssh thanks to netrw:

    vim scp://some-remote-box/some/path

You can jump to a directory listing by including a trailing /

   :help netrw

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.

When you say large, how large is that?

I'm just guessing here, but ripgrep is an executable that they can bundle and write a simple wrapper around. VSCode isn't written in Rust so they'd have to write their own "grep" in Rust which most likely wouldn't be anywhere near as good as ripgrep.

Or am I misunderstanding your question?

Well, ripgrep uses Rust's regex library. If VS code used the regex library directly, then they would basically wind up re-creating ripgrep (or something very similar) itself.

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

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

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.