
Intermediate Vim tips - kinbiko
https://kinbiko.com/vim/my-shiniest-vim-gems/
======
lillesvin
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](https://github.com/BurntSushi/ripgrep)
BurntSushi's write-up about the internal workings of ripgrep is also super
interesting:
[http://blog.burntsushi.net/ripgrep/](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 files.

~~~
huntie
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?

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

~~~
lillesvin
Yup: [https://users.rust-lang.org/t/ripgrep-is-now-the-standard-
te...](https://users.rust-lang.org/t/ripgrep-is-now-the-standard-text-search-
provider-in-vs-code/10285)

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

~~~
jitl
It depends what you use Vim for. If Vim is your only code editor, it’s crazy
that you’d leave tons of productivity enhancements on the table because you
want that standardized, bottom-of-the-barrel experience. Nice things are nice!

I have tons of customizations in my Vim, and have very little trouble using vi
or vanilla Vim when I log into production machines. It is frustrating to not
have my magic this and that, but no less frustrating than it would be going
from IntelliJ on my own box to Vim on someone else’s.

~~~
nemild
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](https://www.nemil.com/musings/betterdebates.html)

------
nulagrithom
> 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?

~~~
minitech
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,
                                       argument_tw
      ↳ o=2,
                                       argument_th
      ↳ ree=3)
    

Turning off word wrap doesn’t help, because then it’s an equally painful
constant two-character scroll. What does help is creating indented blocks
where it feels right, and letting other lines just naturally be long.

    
    
      some_example_code = LongTypeName(
          argument_one=1,
          argument_two=2,
          argument_three=3,
      )
    
      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!")
    

(Plus: specific column counts depend on the size of your indentation.)

~~~
u801e
> 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")

~~~
minitech
> 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."

------
n1cked
I've done a similar thing with my whitespace, but prefer characters that I'm
less likely to have typed myself (like a small arrow for tab).

    
    
      set listchars=tab:→\ ,nbsp:␣,trail:·

------
hzhou321
I am so glad that I can live without these tips. As I grow older, every year I
feel the need to cut down on my essentials. My .vimrc gets shorter every year.
Earlier, I was so annoyed by the default parentheses highlighting yet so
dislike the solutions of adding more lines to my .vimrc, I was forced to do
some research and found out that all I need to do is to delete the plugin from
/usr/share/.... I deleted the entire plugins folder there. I felt like
Picaaso.

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

~~~
mythrwy
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.

~~~
brian-armstrong
I highly highly recommend always using a linter/formatter that just fixes this
for you

~~~
mythrwy
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.

------
unknown_apostle
Having a free day, it's cold and rainy, but this actually made me come out of
bed to crank up vim :-)

------
keithnz
I use vim bindings in visual studio and do a lot of custom binding to
resharper functionality. It's quite magic, the only thing I really miss from
Vim is easy motion and the vim emulation is not complete so for some editing
tasks I have to open a file in Vim.

------
Jeaye
For anyone wanting to peruse another large vim setup (mostly C++ and Clojure):
[https://github.com/jeaye/vimrc](https://github.com/jeaye/vimrc)

------
ekianjo
I dont use fzf but CtrlP for vim is also very good at fuzzy search.

~~~
hitripley
CtrlP is much slower when indexing large directories.

~~~
ekianjo
When you say large, how large is that?

~~~
hitripley
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.

------
geezk7
Do you even emacs bro?

~~~
dang
We've banned this account for repeatedly posting unsubstantive and uncivil
comments to HN.

If you don't want to be banned, you're welcome to email hn@ycombinator.com and
give us reason to believe that you'll follow the rules in the future.

