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.
Re:Vim 9.0
by addcninblue on Thursday June 30, 2022 @06:54PM
(#31939732)
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.
Re:Vim 9.0
by I_complete_me on Friday July 01, 2022 @04:33AM
(#31943836)
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.
Re:Vim 9.0
by hackerbrother on Thursday June 30, 2022 @07:49PM
(#31940248)
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> 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.
Don't forget "set all&" to clear out hellish busted distro / local corp IT defaults
" 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 solarizedCurious 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()
This is the help for the shiftwidth function, not the shiftwidth setting. You need to do :help 'shiftwidth'
See what I mean? WTF.
Re:Vim 9.0
by alisonatwork on Friday July 01, 2022 @12:37AM
(#31942429)
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.
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.
Re:Vim 9.0
by threatofrain on Thursday June 30, 2022 @05:10PM
(#31938659)
No line numbers? @_@
It is already present on the lower right by default. Why lose a column?
Re:Vim 9.0
by bluenose69 on Thursday June 30, 2022 @05:41PM
(#31938993)
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).
Re:Vim 9.0
by sodapopcan on Friday July 01, 2022 @02:29AM
(#31943101)
When I started pairing every day at work, I used to do:
if $WORK_COMPUTER
set number
endif
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.
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
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
Re:Vim 9.0
by sodapopcan on Friday July 01, 2022 @02:30AM
(#31943104)
...and 34gg will save you a chord ;)
It will, but I generally prefer chords on separate hands over double keys on the same hand.
Re:Vim 9.0
by sodapopcan on Friday July 01, 2022 @11:28AM
(#31947767)
I actually agree with you and am now wondering why the heck I’ve used gg all this time.
I mean, I have a 32" 4k monitor for a reason.
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.
Re:Vim 9.0
by avgcorrection on Thursday June 30, 2022 @05:28PM
(#31938852)
Reason being outdated indexing UX?
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
Re:Vim 9.0
by threatofrain on Thursday June 30, 2022 @08:33PM
(#31940625)
You can also set both relative & absolute line numbers at the same time.
Re:Vim 9.0
by I_complete_me on Friday July 01, 2022 @04:40AM
(#31943868)
I have this in my .vimrc to toggle relative on/off with ctrl-n:
> nnoremap <C-n> :exe 'set nu!' &nu ? 'rnu!' : ''
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
> 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).
What's the advantage of this command over "+y ?
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.
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.
It's X11 only. So Wayland or remote users can not use it.
Re:Vim 9.0
by AlecSchueler on Thursday June 30, 2022 @05:23PM
(#31938807)
:set nu!
Re:Vim 9.0
by johncoltrane on Friday July 01, 2022 @11:53AM
(#31948215)
Yeah, why enable a feature you never use?
> No line numbers? @_@
Are you still using goto's ?
Doesn't expandtab mess with creating/editing makefiles?
Re:Vim 9.0
by maxdamantus on Thursday June 30, 2022 @08:24PM
(#31940576)
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
I'm not ok with that. I use EditorConfig so as not to have to remember which project uses tabs and which uses spaces.
Re:Vim 9.0
by Beltalowda on Thursday June 30, 2022 @07:13PM
(#31939923)
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
It’s been a while but I seem to remember being able to configure different tab behaviour specifically for make files.
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.
Re:Vim 9.0
by alisonatwork on Thursday June 30, 2022 @08:58PM
(#31940783)
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
filetype plugin indent onAlmost identical to mine, except I set ai and nu, and wasn't setting shiftround (because I didn't know about it until today!)
Re:Vim 9.0
by calvinmorrison on Thursday June 30, 2022 @11:25PM
(#31941965)
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
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...