Hacker News Reader

Comment by Diederich | Hacker News Reader

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

View on HN

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.

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.

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

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

Me too, dang.

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?

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

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

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

Reply on news.ycombinator.com