Hacker News Reader

Comment by givemeethekeys | Hacker News Reader

I'm curious: - How deep a rabbit hole do most people go down when setting up their vim / neovim environment?

Apart from setting up a preferred color and language specific tab spacing and highlighting, I don't need more, but I've seen some pretty fancy setups.

Out of the different plugins, which would you never operate without?

View on HN

I've been using vi/vim on a near daily basis for 34 years now and this is the only thing I put in ~/.vimrc:

  set tabstop=4
  set expandtab
  set shiftwidth=4 " or 2 or whatever
  set shiftround
  syntax on

EDIT:

Just for some fun archeology, I google searched on the 3rd line, 'set shiftwidth=4 " or 2 or whatever' because I very dimly recall copying most of my standard set (minus the syntax on bit) from someone else a long long time ago. This was the only hit I found:

https://www.perlmonks.org/index.qs1968.pl/perlmonks.org?disp...

No line numbers? @_@

It is already present on the lower right by default. Why lose a column?

I mean, I have a 32" 4k monitor for a reason.

Reason being outdated indexing UX?

I mean, every column counts, even in a 32" 4K display. Also, not all of us have the space to fit these screens everywhere we work.

I like line numbers because when I'm editing code in a remote meeting, I or someone else can refer to lines by number. The current line is not the only one that matters. I use relative line numbers because I like doing e.g. 9k or whatever. Others on a remote call often refer to other parts of the code with "9 up" or "9 down" (since "9k" and "9j" sound too alike in a noisy call).

You can selectively turn them on as a meeting aid, no?

Yup that's what I do as needed, which for me is pretty rare.

When I started pairing every day at work, I used to do:

  if $WORK_COMPUTER
    set number
  endif

But then I came to like line numbers and just have 'em on all the time now.

Then I can easily go to the line I want to go. :34 takes me to line 34

34G will save you a keystroke :-D

...and 34gg will save you a chord ;)

It will, but I generally prefer chords on separate hands over double keys on the same hand.

I actually agree with you and am now wondering why the heck I’ve used gg all this time.

It makes it easy to jump to other lines on your screen, e.g. maybe you want to split out half the code from a loop to another function. You can't use di{ to delete everything in the {} because you only want half of it, but if you can see that the loop contents end on line 98 you can go d98G

Nope. Back in the day that would greatly interfere with copy/paste. One way or another, it's so easy to see what line number you're on and/or jump to a specific line.

can't you just yank to +? you might need the vim build with +clipboard if it's not default these days

I have vim use the clipboard by default, with that said I still use the mouse to copy stuff now and then.

Depending on your OS, you could use visual line mode and highlight the text you want to copy. Then you can run:

    '<,'>w !xclip -selection clipboard

to copy the text to your clipboard. Macs have another program that works similar to xclip, but I don't remember what it's called.

What's the advantage of this command over "+y ?

Not GP, but for me it's simply that I remember it (or rather don't need to, because it's just using general purpose mechanisms that I already remember).

But now you've said it maybe I'll remember if I need it today, and.. well I'll see.

If vim doesn't have clipboard support enabled, then this is one way to copy and paste. The vim packages in the Fedora repositories are configured such that vim doesn't have clipboard support, but gvim does.

> Macs have another program that works similar to xclip, but I don't remember what it's called.

pbcopy

While I'm here, on Wayland substitute wl-copy (or whatever you use).

It's X11 only. So Wayland or remote users can not use it.

    :set nu!

Just toggle them off when you copy/paste, then on again. Takes a fraction of a second.

I gave up absolute line numbers a few years ago in exchange for `:set rnu` and while my navigation capabilities (at least to anywhere I can see) have gotten a lot faster, the ability to `>>` a handful of lines without having to count has felt a ton more productive

You can also set both relative & absolute line numbers at the same time.

I have this in my .vimrc to toggle relative on/off with ctrl-n:

> nnoremap <C-n> :exe 'set nu!' &nu ? 'rnu!' : ''

> No line numbers? @_@

Are you still using goto's ?

Yeah, why enable a feature you never use?

TIL about set shiftround... that would definitely help with > commands...

Me too, dang.

Doesn't expandtab mess with creating/editing makefiles?

It surely can. If I have to casually mess with a Makefile, I'll just remember to use control-v TAB as needed, or vi yank/put another line with a proper tab and edit. In the very rare case I'm doing more serious work, I'll temporarily turn it off.

It’s been a while but I seem to remember being able to configure different tab behaviour specifically for make files.

The ftplugin for the make filetype includes setlocal noexpandtab, which should take precedence over what's in your vimrc.

  % vim Makefile
  :verbose set expandtab?
  noexpandtab
    Last set from /usr/share/vim/vim90/ftplugin/make.vim line 15
  
  % vim file.c
  :verbose set expandtab?
  noexpandtab
    Last set from ~/.vim/vimrc line 56

but I think that may not work as intended for OP as they don't have "filetype on plugin".

I really wish more systems would adopt the "copyindent" pattern, where indentation is simply copied from the existing line. I've primarily developed in vim for 15 years and have similarly minimal `vimrc`s (no plugins), but some of the first configurations are always:

  set autoindent
  set copyindent
  set preserveindent

This should be compatible with basically any language (other than some esolangs like "whitespace") and any tab/spaces scheme. There's no need to have per-file/project configuration, as long as you're okay with pressing space 4 times instead of tab in the projects that use 4-space indentation.

I'm not ok with that. I use EditorConfig so as not to have to remember which project uses tabs and which uses spaces.

You can change it per filetype. For example, I have a similarly minimal vimrc that defaults to sw=4, ts=4 and expandtab, but with the following additions:

  autocmd FileType go,make,sh set noexpandtab
  autocmd FileType js,json set sw=2 ts=2

Edit: I think you might also need the following to make it trigger the FileType event when you open a file in the first place:

  filetype plugin indent on

Similar, but you can do most of those in one line! I also turn on line numbers and map "jk" to Escape in insert mode:

    set expandtab shiftwidth=4 softtabstop=4 tabstop=4
    syntax on
    set number
    inoremap jk <Esc>

I tried that 'jk' thing way back, and I seem to recall it introducing some lag. Like a few milliseconds so it could process and see if you were hitting the followup key. Just enough to be annoying.

The lag thing is due to this:

If you type `j` in insert mode, it waits to see if there's a possible `k` following. That's the lag.

There's a setting for how long it waits.

I have the following in my .vimrc

> set timeout timeoutlen=3000 ttimeoutlen=100

Heh, jj for me and ji in visual mode since I might use jk there.

Almost identical to mine, except I set ai and nu, and wasn't setting shiftround (because I didn't know about it until today!)

My one non-negotiable config option is swapping ; and : because not having to deal with chording is a big perk of vim for me.

I have a simple one too--

    set number
    setlocal cm=blowfish2
    set noswapfile
    set nobackup
    set nowritebackup
    set viminfo=
    set tabstop=4
    set softtabstop=0 noexpandtab
    set shiftwidth=4
    set noundofile
    set backspace=indent,eol,start
    set autoindent
    set smartindent
    set cindent
    autocmd BufRead,BufNewFile *.vue setfiletype html
    colorscheme morning
    
    map Q <Nop>
    map q <Nop>
    noremap x "_x
    
    let &t_ut=''
    
    if has("gui_running")
     :set guifont=Cascadia_Mono:h16:cANSI:qDRAFT
    endif

Don't forget "set all&" to clear out hellish busted distro / local corp IT defaults

> map q <Nop>

you turn off macro recording? any particular reason why?

Not the person you’re replying to but I’d guess that they don’t ever record macros and just find it to be an annoyance if they accidentally press the Q key by accident.

You're probably right; vim macros are almost the entire reason I personally prefer vim to vi, I can't imagine not using them.

   " My vimrc from 1994 to about 2000
   set et
   set ts=4
   " Added this circa 2000
   syntax on
   " Added this ~2013
   let g:solarized_termcolors=256
   set background=light
   colorscheme solarized

Curious as to why you set ts but not sw?

because i've always found the vi documentation a bear to navigate. i don't know what shiftwidth is even for. here's the help for it:

shiftwidth([{col}]) shiftwidth() Returns the effective value of 'shiftwidth'. This is the 'shiftwidth' value unless it is zero, in which case it is the 'tabstop' value. This function was introduced with patch 7.3.694 in 2012, everybody should have it by now (however it did not allow for the optional {col} argument until 8.1.542).

                When there is one argument {col} this is used as column number
                for which to return the 'shiftwidth' value. This matters for the
                'vartabstop' feature. If the 'vartabstop' setting is enabled and
                no {col} argument is given, column 1 will be assumed.

                Can also be used as a |method|: >
                        GetColumn()->shiftwidth()

What does that even mean? And I've been using vi since 1988!!

shiftwidth has been in vi for a very long time. It's been in my exrc since I got into BSD in the 1990s, and judging by the earliest commit that's available online[0] it was added even before 1980.

[0] https://github.com/weiss/original-bsd/commit/3effe8f62d3c7b5...

tabstop is how far the cursor moves when you press tab.

shiftwidth is how far text moves when you shift it with >> or <<

Normally you'd set them both to the same value so that indenting blocks of code with >> or << shifts them by the same amount as the tabstop.

There's also another setting 'shiftround' (which I only learnt about today in another comment) which makes shifts done with << and >> round themselves to the nearest multiple of shiftwidth.

i've always used 0i\t\t\t\t...\esc to shift.

never occurred to me to use >>. probably because the three keystroke savings didn't register with me. but that's what I mean, once I learn the basics, the rest are just gravy that don't stick in my memory.

Using < and > for shifts becomes even more powerful when combined with a movement, e.g. indenting 20 lines of code at once: 20>> or indenting an entire {} block (including braces) >a{ or an entire block (not including braces) >i{

> i've always used 0i\t\t\t\t...\esc to shift.

Also consider I instead of 0i (it's not quite identical, but should serve the same purpose).

It saves way more than 'three keystrokes' redenting a block though - you must do that every line - I typically visual select then > (or <), doing the whole lot in one stroke (excluding whatever variable amount to select, v} or similar often).

I only ever end up actually manually shifting code when I'm pasting python code from somewhere and it doesn't come in with the right indentation.

If I'm working in any other language it's == (for a single line), or = after marking a region in visual mode, or magg=G'a to just re-indent the whole file.

I haven't used vim as a daily driver in ~14 years; it's weird how the muscle memory of things like magg=G'a or gqip stay in your fingertips.

This is the help for the shiftwidth function, not the shiftwidth setting. You need to do :help 'shiftwidth'

See what I mean? WTF.

I may get flak for this but I have done it since I started using vim more than a decade ago...

noremap ; l

noremap l k

noremap k j

noremap j h

Having gone from a stock vim to a highly modified vim and back again, here are some plugins that I find really boost my productivity:

- neoterm, for opening a REPL in a split buffer and quickly sending chunks of lines to the REPL (https://github.com/kassio/neoterm)

- fzf for faster buffer and file navigation (https://github.com/junegunn/fzf.vim)

- vim fugitive for good git integration (https://github.com/tpope/vim-fugitive)

- some other tpope plugins (surround, unimpared, commentary, vinegar)

I've spent so much time on configuring my (Neo)vim over the years I wouldn't even be able to estimate it (here it is if you're curious: https://github.com/kirillbobyrev/dotfiles/tree/main/.config/...).

The most important ones lately seem to be the LSP integrations (basically IDE features like autocompletion, go-to-definition etc) and auto-completion managers. But honestly it's been breaking all the time over the last year or so that I code more often in VSCode and maybe it's about time I stop trying to make an ever-improving IDE out of Neovim :(

Neovim project's direction seems to be aligned with making it easier to have IDE-like experience with LSP integration but it's been painful in Neovim. In Vim, it's typically even worse and even harder to set it up.

Overall, I've been using Vim for about 8 years and went from a really simple set-up of "this is just a text editor" down the IDE rabbit hole. I also went for Vim -> Neovim -> Vim -> Neovim and eventual split of the two configs in the end and. I'm thinking about making it much simpler again :D

It depends what kind of person you are, how much energy you want to invest, how much patience you have for stuff that isn't the code you're writing, how much you enjoy editing itself, etc.

I have a quite extensive setup (https://github.com/Julian/dotfiles/tree/main/.config/nvim) which I built up over 10+ years, indeed sometimes including sitting there for an hour or two and just investigating plugins or writing some function to make editing easier. I enjoy it, and it means I can do lots of things in my setup that involved time investment.

Others obviously just want to get on with their work.

To me though part of the reason I use vim/neovim is because anytime something annoys me about editing I can automate it, or find a plugin which has done so already.

This is what I love about vim. Ironically, I think that the barrier to writing a plugin that solves your problems is lower in vim than an IDE. Pair that with portability, and you have a cozy environment you can feel safe investing hours into.

No idea if I'm typical or an outlier, but I have a couple of syntax highlighting plugins, NLKNguyen/papercolor-theme, a vim rc file with my favorite keybindings (e.g. faster navigation among splits), and a python file with some helpers for opening terminals in vim and... that's it.

Every once in awhile I think I might do a fancier setup but then I lose interest. Ditto for checking out neovim. I'm sure I'd get some gains, but I guess I've sort of settled into a decent sweet spot that I haven't left for almost a decade, haha (been using vim for ~25 years total).

For me, I'll say "never ending-ly" deep. I've been hacking on Vim for the last 20ish years. First plain old Vim, and in the last 3 years, NeoVim. Even this morning I started by switching out VSnips (snippet manager) for Luasnip. I am always looking at things that could make my dev life more streamlined. I don't really care so much about having a bunch of bling plugins (although I do have a nice status bar, and a file tree). I'm more looking more at the things that I do on a day to day basis. Are there existing plugins that fit those patterns? If there are, I try them out. Sometimes I have to write the functionality myself. (Want to console log the variable under my cursor, with a label? Done.)

Since this editor (and Emacs) are SO extensible, it's hard to find two long-time users with similar configs.

I think this really depends on whether you have a good way to track your dotfiles or not, as configuration is accretive with time: you make changes as you find you need to scratch an itch. Config changes are lost without some way to sync across systems.

Previously to managing my dotfiles, my .vimrc was usually 4-5 lines, written by hand on each machine I sat at. This was my first 20+ years of vi/vim.

Once I started managing dotfiles across systems (~3 years ago), my .vimrc has grown to be ~700 lines. My .bashrc has also grown to almost as much for reference.

Like most, the work in customizing .vimrc is in configuring plugins and making sure they don't conflict with each other, but also, I've taken care so that I can use the same configs across Linux and Windows, allowing me to use the same tools, plugins and configurations regardless of the underlying OS. Neovim is my tool of choice on both OSes but my configs fallback well to vim or other vi implementations rather gracefully (via bash/pwsh alias trickery) for when needed.

Regarding plugins that I would never operate without (of the many installed): - nerdtree (and friends like nerdtree-git-plugin, vim-nerdtree-syntax, vim-devicons) for decent file nav integration - vim-fugitive (Git integrated into vim, makes interactive commit creation and navigation easy from within vim) - Coc for language server support that works on both sides of the fork and vscode like plugins.

Also, not a plugin, but worth configuring in your environment: neovim-remote. I use this to make "vi <file>" open the file in a new tab, rather than start a nested editor, from within a terminal window within neovim (again with more shell alias trickery dependent upon $NVIM_LISTEN_ADDRESS being set or not). Using it for $EDITOR and $VISUAL when NVIM_LISTEN_ADDRESS is set is also really useful when invoked indirectly by tools being run in a windowed terminal e.g. "git commit" or "kubectl edit".

If you aren't tracking dotfiles, I really suggest you start. It's really cool to be able to sit at a new system, sync some files and get your editor / development environment installed/booted with all the bells and whistles you like installed ready to go. You will find that there is no end to this rabbit hole in the end. I think that's a good thing :)

It's only a rabbit hole if you want it to be one.

Vim only has that reputation of needing a lot of config because too many newbies want to skip the learning phase and just jump in between two JIRA tickets. Of course you will need a lot of plugins and pre-baked stuff and hand-holding in that case!

The more sensible path is to learn Vim properly, and configure it as you go. It means that there's never a "take the week-end to configure Vim for React" moment: it's one line here, two lines there and it never really stops because you work with new languages and libs, etc.

As far as plugins. I can use Vim just fine without plugins or without my config but half of the plugins I use are written by me and tailored around my own needs so I guess those are the ones I need the most for my daily use.

I put some time into learning vanilla vim to a fairly basic level, about 20 years ago. It’s been sufficient ever since. Occasionally I look up rarely used commands, but as far as I’m concerned my configuring days are over.

It’s definitely a deep rabbit hole. There’s a lot to figure out - even as an old vim user moving to a more modern neovim setup about a year ago.

One of the issues I found was that every plugin seemed to reference other plugins and you need to figure out how to make them play nicely together yourself. Most of the best info is just buried in GitHub issues and neovim was such a moving target that everything needed more digging into to get working correctly.

For me now essentials include; Telescope, Trouble, Cmp and a good LSP setup.

    $ du -s -h .vim
    22M .vim

A lot of that is git submodule history.

Specific plugins I use all the time: bufexplorer (though I've mostly rewritten it), ctrlp, colorizer, syntastic, vim-commentary, vim-projectroot, vim-surround, zeavim (Zeal integration, similar to Dash on macos).

Definitely ALE. Being able to use LSPs is the only reason I haven't switched.

Out of everything, if I want to use (neo)vim as a serious code editing environment, it has got to be LSP support. To that end, I use coc.vim although of course there are many other LSP plugins.

Check out LunarVim, it is excellent.

Also nvchad if you want to easily override builtin config from the starterkit.

I don't set anything. I use vim as vi.

I've gone down that rabbit hole quite a few times and each time for a much longer period than I am willing to admit. I use neovim for hobby development and as a general text editor.

The plugin that I find myself using all the time is vim-surround with a couple of minor language-specific tweaks.

ALE and CTRLP are the most non-vimmish ones I guess. Most of my remaining plugins are extensions to Vim, like highlighting unique characters when pressing f, or highlighting my latest yank, or more text objects, or autopairs, surround, etc.

The fzf plugin is really nice for navigating through files and for code search, but not really necessary.

The editing plugins I use most heavily are probably vim-surround and vim-commentary. My development would definitely slow down without them.

I have got a stable setup and been happy with for many years now.

I would say that the plugins I could not do without are:

- vim-polyglot

- syntastic

- nerdtree

- coc.vim

.vimrc currently sitting at about 275 lines (including whitespace and comments). A big chunk of that came with the terminal integration, as I'm using `term_sendkeys` heavily.

I'd always use airline and show a buffer line with it.

surprised noon mentioned :set hlsearch

Reply on news.ycombinator.com