Hacker News new | past | comments | ask | show | jobs | submit login
Five lines I put in a blank .vimrc (swordandsignals.com)
153 points by jiannengli 82 days ago | hide | past | favorite | 131 comments

I find it odd that you would use the short version of a command in a config file. Brevity is important when you are doing repetitive tasks. In a config file (or code), clarity is more important that brevity. I know you could argue that you know VI so well that you know these commands off the top of your head.. even so, it's particularly pointless to list them this way in a blog where you have to turn around and explain them anyhow.

Yes, I definitely am much descriptive for the config file on my personal computer. The configs I'm recommending here is more for ephemeral machines that you are using just to look at files (such as sshing into a VM that was created to run integration tests). For those cases, being able to quickly type something into the .vimrc and improve your experience is nice.

I once had to connect to machines regularly where I did not have a home directory. This happened so often that I wrote a wrapper to log in:

It would log into the remote machine using Expect, then it would send a command to the remote end that tested whether a home directory already existed. If so, it spawned a new shell in it. Otherwise it created a "home directory" in /tmp, pulled a tarball from a server, and extracted it into the "home directory". Then it spawned a new shell there.

Depending on how often it happens, you could also have a separate command that does the initial setup, and then call that as required.

That's cool. Do you have a write-up of this somewhere?

Thank you for giving me a reason to start a blog :-)

I guess I don't see a lot of situations where I use systems so casually that I don't have config options set. Even when I was managing a bunch of systems I would push out the same config on them all.

One scenario I could see this fitting is when having to connect to some docker container and test a change on the fly.

That's a bit naughty but sometimes needed to prove something useful.

In that case you've got an effemeral file system, and probably had to install Vim in the first place, knowing that that when you close the container all will be forgotten.

Ofcourse in that situation you probably don't need to disable the Vim swap files, so that's one less thing to changet the defaults on.

I often use Busybox for that kind of thing as you're usually missing other useful OS stuff and its little Vi clone is usually enough.

As discussed in the article, the point is to quickly set up vim on fresh linux installations (e.g. virtual machines). For the vim on your own pc, you would likely use the full version, in addition to whatever extra config you prefer.

It's not a big deal. You can just hit K on any you're not sure about to see the help. Might need to set keywordprg=:help.

> Might need to set keywordprg=:help.

    echo 'set keywordprg=:help' >> ~/.vimrc

On a new machine with a blank vimrc you’d probably just be piping in these commands in from the command line so it’s more convenient if they are short.

The swap file saved my work a number of times. If you never use recover and use Vim regularly, then go ahead and disable it; if you haven't used it because you don't know how to use it or you only rarely use Vim, then I'd encourage you to either try it first or leave it enabled (as it is by default) until it becomes a nuisance.

And like u/strogonoff, I also disable line numbers, but that's just personal preference of course. For vim newbies, relative lines might also be worth checking out: "set relativenumber".

One thing that really annoys me is :Wq or :Q not being commands. Or typing only Q because you didn't hit the : and accidentally entering ex mode. Or hitting F1 instead of escape. I can recommend:

    command Wq wq
    command WQ wq
    command W w
    command Q q
    nnoremap Q <nop>
    map <F1> <Esc>
    imap <F1> <Esc>
Or for the non-newbie that has the 'too many terminals' problem, "set title" will give your terminals more useful titles. There are a bunch more things, of course, but these are the lines in my vimrc that I think are useful to most people.

I hit :w so reflexively and regularly in working files that swap files only occasionally saves my butt: when I've done substantial work in a new buffer that I haven't figured out how to name yet and there's a crash.

This happens just often enough that I have to regard it as useful, but it's also less common than crashes that leave me with swaps to contend with across a dozen files that really were pretty much fine. This is a frequent annoyance.

So: occasional big help vs frequent annoyance.

I don't think the problem is actually swap files themselves, though, but the user experience with them. What vim does is prompt you to choose what to do before you've even had a chance to compare the swap with what's saved, and provides no help with the comparison. What'd be nice is if it gave you some kind of visualization of a diff between the two and then prompted you for a choice.

> I don't think the problem is actually swap files themselves, though, but the user experience with them.

Agreed, the UX is 99% the reason of me hating swap files. More often than not I choose recover, only to discover the diff is literally null. Come on, you could not check for that before interrupting? And then in any case you have double the annoyance with that recovered buffer as the old swap remains and you have to delete it or you get the warning again on the next open.

It’s kind of like changing branches with git and then back again, vim notices the time stamp of an opened file changed vs the last buffer save, lets you change the file but complains on :w that the file “changed” outside, yet is unable to a) show you a diff of current buffer vs current file, nor b) realised that the filesystem state vs buffer state at last save (which vim fully knows about) produces a null diff, so the buffer changes are safe to write.

> only to discover the diff is literally null.

Note that you can save the trouble of running diff by watching for the message "Buffer contents equals file contents." Only when they're different, you'll want to write the file to another place and diff it.

What bugs me a lot is that, even if the contents are equal, it doesn't cleanup the swap file... is there maybe a command for that so I don't have to go back to my terminal, manually remove .<filename>.swp, and open up vim again?

I don’t think you even need to write, I have this shortcut[0]:

    nmap <leader>d :w !diff -u % -<CR>
It writes the buffer’s content to diff’s stdin, and diff gets passed the filename (hence the current on disk content) to compare vs stdin (hence the current buffer content).

Only I wish it were run automatically by vim in aforementioned cases before whining (case a: recover, run the above, if no diff stop complaining; case b: rewind til last save, run the above, if no diff then replay and save without complaining)

[0]: https://github.com/lloeki/vimfiles/blob/9c50f3be60e536518beb...

> I hit :w so reflexively and regularly in working files that swap files only occasionally saves my butt

I'm definitely one of those people too, and while I don't disable swap files I do depend heavily on `persistent-undo`. It literally changed the way I work when it was introduced. To some extent I treat it as an extension to swapfile functionality as it also operates across broken sessions(intentional or not).

> [...] the user experience with them

Christian Brabandt's Recover.vim¹ is a huge improvement for those few times when you do actually want to work with a swap file. General recommendation to poke around in his other repositories too, as he has written a heap of extremely useful vim things.

Edit: Especially unicode.vim² which improves `ga` no end, csv.vim³ which feels like magic, NrrwRgn⁴ for fellow emacs refugees, and ...

¹ https://github.com/chrisbra/Recover.vim

² https://github.com/chrisbra/unicode.vim

³ https://github.com/chrisbra/csv.vim


100% agree on that last paragraph.

For what it's worth, Vim never crashes on me. For me swap files are mostly helpful with broken connections, killed VMs that apparently still had a vim session open in a faraway terminal, or other such situations.

> relative lines might also be worth checking out: "set relativenumber".

I really like the behaviour of `set number relativenumber`, where it shows me my actual line number of the current line and relative numbers on the lines I'm going to operate on.

Yes, I resent that this is for newbies some how. It's a small visual aid and unless you're using a tiny terminal it's hard to be able to do a 78d by sight.

> Or typing only Q because you didn't hit the : and accidentally entering ex mode.

I'm not certain this is different (because I don't use either deliberately) but I'm forever hitting q (not even trying to quit) and entering some kind of macro recording mode.

I think the only reason I haven't yet disabled it like you suggest (after doing it for years now) is that... Well 'some kind of macro recording' does sound like it might be pretty useful if I bothered to learn to use it!

Macros are really nice, you can automate transforming several lines of text with them. The Vim plugin in Intellij supports them. Worth learning IMHO.

Indeed, I would not recommend disabling q unless you know what it does and tried it a few times.

For a quick demo, try it on this file:

    hello world!
    here's wolves
    what's up with the hackers?
Go to the first line and do:

    1. qq starts a macro named 'q'
    2. $vbgUj select last word on line, uppercase it, go down one line
    3. q to end macro recording
    4. @q run the macro
    4b. @@ repeats the last macro
    4c. 100@q runs the macro 100 times
When you want to do multi-line edits and the columns are not aligned (so block mode, Ctrl+V, doesn't work), this works wonders. You just record whatever you would do on every line plus whatever motions you use to go to the next occurrence, using things like "f|" (find the next pipe symbol) or "/example<Esc>n" (find the next instance of "example"), and then run the macro however many times. If you specify a number of times greater than the file is large, it will automatically stop at end of file, and you can also cancel if it takes too long (Ctrl+C) and undo what it did so far (u).

Alternatively, sed -i s/a/b/ my.txt is much much faster than macros, but macros can be more complex and are often easier to record (since you're just showing the computer what to do in a human way) than trying to regex the line.

I tried recording it for the lazy but asciinema is having issues (server error when uploading).

inoremap jk <Esc>

inoremap kj <Esc>

are essential to me... press both at the same time and you exit insert mode regardless of which one gets pressed slightly faster and you never leave the home row and if you press it when you are not in insert mode it's basically a nop unless you are at the start or end of the file. even if you are you might move down or up a line accidentally but i've never had that happen personally.

I tried that, but found it annoying to occasionally get kicked out of insert mode while writing. I ended up rebinding Caps Lock to Escape instead, with Shift+CL to toggle caps; I quite like this rebinding even outside Vim. Two lines in autohotkey on Windows, or setxkbmap in X11.

This is the first thing in my config, whenever I try to setup in a new system. Now "kj" and ":w" has become more like a muscle memory, even when I am just staring at the abyss...

Then you can't type words that have jk or kj in them, right? :) Depending on languages used it could be a blocker

you certainly can. it just requires you to wait whatever the timeout is set to. it doesn't come up all that often and i've used it for a long time.

Personally I get round some of these problems by using :x instead of :wq for write/quit.

It's one letter shorter and less likely to be confused.

Why not one line?

    set hls ic is nu noswf
On a serious note, personally disabling line numbers is the first thing I do in a new editor. Reduces visual noise—status line usually shows current line number anyway, jumping to a line might take a second and I found I don’t need to know my line numbers more frequently than once per month or so.

What I do like to enable in an editor is visible whitespace characters (helps notice levels of indent, for example). In Vim that can be accomplished with:

    set list listchars+=space:•
(Might take some tweaking to make whitespace appear subtly enough, depending on your color scheme.)

Interesting. The first thing I always do in a new is enable the line numbers. I pair-program a lot and find them to be invaluable when talking about the code.

I can see how line numbers would be immensely useful if I ever pair program remotely.

Line number are super helpful for navigating in vim, though. :54 when you’re on line 20 is much faster than any alternative.

Some folk like `34d` so they don't need to press shift. And sometimes set relative line numbers so they don't need to do the subtraction.

Others just search for known text, which IMO is a habit I need to get into. I "got" hjkl after I disabled the cursor keys for a day, but I never followed up and disabled hjkl (or maybe even w and b!?) to get super efficient.

I often navigate with the search. It's fast as I usually know where I want to go.

Also with the right setting(I think incsearch) Vim immediately jumps to the first result as you type, so I often use search to quickly peek at some code and then jump back with Esc when it doesn't warrant splitting the buffer.

But I do still struggle a bit with moving within the line - w and b tend to "get caught" in long series of different symbol categories that Vim will all see as separate words/tokens. At least I got my setup with the "camelcasemotion" plugin working, which is a great help with long identifier names.

You can just use 54gg, no shift involved.

I have never considered disabling hjkl, quite an interesting idea.

I use H, M, L to move the cursor to the top, middle and bottom of the screen, and ctrl-f and ctr-b to scroll half a page, which drags the cursor along for the ride if it would otherwise be offscreen.

I see, I suppose it depends on one’s habits then. Personally I’m used to roughly approximating relative jumps or using search to arrive at the desired identifier, but then I wouldn’t call myself especially efficient.

The only time I find using :number is when I am exploring a codebase elsewhere, e.g. using GitHub’s web interface, and want to jump to a particular line in Vim to make edits—rarely happens.

I would type "8j8j8j8jjj". I type "8j" (and "8k") a lot.

I bind those commands to "shift-j" and "shift-k" and heavily abuse them.

It's not pretty, one could argue that the mouse is more efficient for such movements, but for me it's faster in practice than moving my hand to the mouse/trackpad, or than looking up a line number (either absolute or relative) and then typing it. And it has no mental burden.

I usually go with { and } for those to jump between paragraphs, as that is usually a sensible distance of movement. But your approach is also an interesting addition as it's more consistent.

I use them heavily. Also, check out ]] [[ and ]m (jump to end of function).

Thanks, I didn't know about putting everything on one line. I've updated the post to include this tip.

As for showing line numbers, I'm often doing this to read logs on a remote VM. In those scenarios, having easy access to where you are in the file is really helpful.

For spaces, I have:

    set listchars=tab:>-

    set listchars+=trail:⋄
This shows markers for tabs and trailing whitespaces.

The latter will make you very sad when you browse other people's code.

Funny you say that about the visual noise because as someone who’s dyslexic, I find line numbers actually help with readability since it is easier for me to remember a number than it is text.

I also find it especially useful in vi when working with config files. I’m sure you are aware of this feature but in case others aren’t, in vi if you type numbers before a command, it runs that commend n times. So you can quickly copy or delete multiple lines.

It just goes to show how deeply personal a preference a persons code editor is.

Indeed, to your last sentence.

I use shift+v and a j/k relative jump to select a range of lines, then do the operation. Which is undeniably the slower way.

Didn’t know how dyslexia affects this, I will keep that in mind in case I happen to work with someone with it.

    set list listchars+=space:•
This adds a lot of clutter! It's better to show only indentations (of course, using tabs):

    set listchars=tab:├─

Line numbers are great, until you try to cut and paste. But then again, VI/M wasn't designed for GUIs.

I have the default register mapped to the system clipboard so doing yank in vim I can paste into anywhere else - no need to use the mouse or worry about line numbers

    " mac clipboard {{
    if has("clipboard")
      set clipboard=unnamed
    " }} mac clipboard

If your vim is compiled with the correct flag for GUI operations (I forget which), you can yank/delete text into the * or + registers to make it available to the system clipboards. This won't bring the line numbers, and lets you avoid using the mouse.

I think it's just called +clipboard. And with the setting "set clipboard=unnamedplus" Vim will use the system clipboard for yank, delete and paste by default.

I use vim in a terminal, the way the gods intended, not gvim. ;-P

But apparently according to peer comments, there are ways to yank into clipboards, which is pretty cool.

Not only that but if you set your mouse up correctly then you can use the mouse for selections and have it respect window splits too.

That works in tmux too. So you can have use the terminal but have it behave as a GUI app in most respects. For example being able to use a touchpad to quicly enlarge/resize splits or scroll a window can be quite useful.

This works with standard vim in a terminal as well. I too follow the old gods.

I don’t copy and paste, I just don’t see the need for line numbers. But then I also code with syntax highlighting off about half of the time.

Yay im not alone!

I've always found syntax highlighting super distracting, but everyone i have met thinks im crazy.

Otoh i do love me line numbers.

> But then I also code with syntax highlighting off about half of the time.

Wow, don't ever use VSCode then! There are hovering diacritics and proofing marks everywhere!

It does real-time syntax checking and quick compilation to check interfaces (at least with TypeScript, JS, HTML, pug, css, Vue, and NodeJS).

I resisted fancy editors for years, as I found them crazy annoying, but over the past few months I've grown to adore VSCode because it has made me about 50% more efficient: I don't have to run the app to find errors, the IDE finds them for me, and it works on Win10, macOS and Linux. It is extremely context aware of my project.

It's like JetBrains but free (or Android Developer Studio, also made by JetBrains...).

I actually use VSC in Vim mode for TypeScript work as I couldn’t get Vim to nicely show verbose deeply nested typing hints (maybe someone knows a way?). There is a “mono white” theme, it still shades a few keywords in grey but otherwise is pretty good.

Very interesting, I don't think I've ever talked to someone who would choose to disable syntax highlighting. Do the colors actively annoy you or is it just that you don't care?

I tried both ends of the spectrum.

There’s definitely something real about too much colours; the archetypal example of colouring our human language tokens by type (verbs, nouns, etc) making no sense sure rings home after a while.

But I found very much use of “colour”+ themeing for two things:

- comments vs code, one toned down vs the other, ideally swappable with a hotkey

- delimited content such as strings. It sure saves a lot of time when you get an imbalanced delimiter nested in a forest and the whole of your file changes colour starting near the imbalance.

I’m very much of the opinion that a lot of syntax highlighting is just dumbed down token matching and badly designed (if at all designed), when it should be much smarter in alerting you of inconsistencies, and putting relevant content forward.

+ by colour I don’t necessarily mean literally in colour, bold or italics can serve well.

I am looking forward to smart highlighting that does what you say (marking errors and inconsistencies, like perhaps a truthiness check being used with a variable that could be both null and undefined in case of a typed language) and otherwise is based on context (for example, highlighting a variable that was defined in outer scope is something that could be legitimately useful).

Colouring human language by tokens is a very fitting analogy.

I have seen some C code so heavily #ifdef'ed that toning down the parts that are excluded in the current build would be helpful.

Count me as another. I find syntax highlighting to be distracting unless it is done with some restraint (which it rarely is), and not helpful enough for me to bother with coming up with my own scheme or searching for one that I like.

I am sure there are corner-cases where I would want to enable it, such as were someone has been in the habit of commenting-out parts of a line.

I don't know anyone who uses syntax highlighting for natural-language prose, though I suppose there are some who do.

I find that not having highlighting to rely on forces me to write more readable code. I might turn it on if I happen to work on a hairy codebase under time constraints.

Sometimes also colors in general can get distracting and I just turn on grayscale system-wide, which also doesn’t play with syntax highlighting as text ends up being varying shades of gray with not enough contrast against the background.

I grew up without it and I think my brain is wired to recognize visual structure instead of colors.

Switching it off is the first I do.

Hah, I'm the exact opposite. Greatly enjoy very colored themes, but it feels like almost all themes are about 50% white text with only a handful of things colored.

I set F12 to toggle line numbers off/on. Very quick and handy.

:nmap <F12> :set invnumber<CR>

Another approach to the swap file thing:

    view foo   # opens read-only, no swap file
    vi foo     # opens read-write
Another benefit of this habit is, if you know you're not going to want to modify a file, you can protect yourself against errors like accidentally changing something and then absentmindedly saving the file.

Nice, that'll come handy

Keeping the swapfile on is really helpful when I accidentally open the same file in two different vim editors. But I do recommend configuring vim to place swapfiles in a different location, so you’re not scattering them all over your disk.

I actually went full on in the other direction and often have multiple vim instances working on the same file. It feels so much better than having to deal with swap file error messages. With the below it reloads the file when the window gets into focus. Super helpful when working in lots of terminal tabs. You just have to get into a habit of saving after every change as it conflicts otherwise.

    " check for and load file changes when a window is focused. Together with
    " `noswapfile` this allows to edit the same file in multiple nvim instances and
    " have the changes reloaded whenever the focus is changed.
    autocmd WinEnter,BufWinEnter,FocusGained * checktime

Maybe could have it work on a cloned temp file, and then autosaving on losing focus. Opening the same real-file would lead to the same temp-file. Might be able to make manual :w save the temp to the real, but may be better to have it as a separate command.

Can't you also auto-save when losing focus?

Hah, I would think so. I'm not really familiar with the scripting side and end up searching for solutions online.

See [0] for something to try.

[0] https://vim.fandom.com/wiki/Auto_save_files_when_focus_is_lo...

why would you need to open the same file in multiple tabs instead of switching tabs to get to the file.

in the few cases where i really need to open the file multiple times i use tmux to allow a shared view.

Mostly because I'm using kitty [0] and the tab and split-view handling in it is super quick and effortless. For example instead of opening a :vsplit in vim I just split my terminal and open a second instance on vim on the same file. You lose pretty much all the advanced buffer handling that vim offers, but I never used them much in the first place.

It's a bit crude but I really like how it results in a uniform way of working in the terminal. As opposed to handling different files and processes depending on what applications is currently running.

[0] https://sw.kovidgoyal.net/kitty/

oh, i see. in large files you may want to see multiple sections to compare them. i usually use less for that, view (which is readonly vi) also works well. and of course i realize that opening multiple tmux views with the same window doesn't even help with that.

These seem a bit too opinionated to me, mostly because of 'set noswapfile'.

For me vim-sensible [1] has a more useful set of defaults (although more than five lines). Also, the readme of that project lists benefits of using a universal set of defaults.

[1] https://github.com/tpope/vim-sensible

I'd prefer one line it and use the "long" names and add nocompatible

    set nocompatible hlsearch incsearch ignorecase number
then sane tabs

    set et sts=4 sw=4

I switch between enough different projects with different coding styles that I have shortcuts to change between them:

    set expandtab
    set shiftwidth=4
    set softtabstop=4
    function Spaces(...)
        if a:0 == 1
            let l:width = a:1
            let l:width = 4
        setlocal expandtab
        let &l:shiftwidth = l:width
        let &l:softtabstop = l:width
    command! T setlocal noexpandtab shiftwidth=8 softtabstop=0
    command! -nargs=? S call Spaces(<args>)
    autocmd BufNewFile,BufRead ~/src/linux/* T
    autocmd BufNewFile,BufRead ~/src/git/* T
    autocmd FileType html S 2
    autocmd FileType tex S 2
This sets the default to 4-space indents, but lets me do :T to switch to tabs (and does so automatically for Linux and Git which use that style), or :S N to switch to N-space indents (and automatically switches HTML and TeX to 2-space indents).

I use vim-sleuth to auto-detect indentation settings.


Thanks, I've edited the post to mention about putting everything in one lien.

Why nocompatible?

Not necessary, AFAIK, unless you invoke vim using the alias "vi". If you call "vim" it'll start in nocompatibe mode by default.

The nocompatible mode means adding some features to vim rendering it "incompatible" with the original vi. For example in the original vi you can only undo the last action, with compatible mode on vim will mimic this behavior.

Takes a whole stroke off your shell game!

> Unfortunately, Vim’s default configurations lack several important usability features compared to popular alternative text editors, such as VSCode.

I find it odd, to compare Vim with VSCode and pretend that those 5 lines close the gap (especially when 3 of those lines are primarily about search). My own .vimrc has 166 lines (custom snippets, key bindings, plugin configurations (e.g. powerline, tmux navigator) and comments) and I try not to use more plugins than necessary.

I say that as someone who loves Vim. But not just for its features, but also for those that are not present (by default) and make it as fast as it is.

Line numbers can be quite handy when coding with somebody over a video connection. Instead of saying "I think the problem is 8 or 9 lines up from the cursor", it's just easier to say "look at line 314" or whatever. I seldom use j and k to go more than a line or two, preferring absolute or relative line jumps, and I find absolute jumps easier to do accurately, especially if I'm tired.

I guess it depends if you are doing systems admin or coding, but when I'm coding, I've gotten very dependent on Fuzzy Search like what Sublime Text introduced.

So for me, installing CtrP or FZF is pretty much mandatory (I've settled on FZF). I know this is about config options, and this is an extension, but for me, fuzzy search is pretty much essential for coding once you get to a moderate sized code-base.

It’s not enough. You should go all the way:

    set nobackup
    set nowritebackup
    set noundofile
    set noswapfile
I explain why at https://lee-phillips.org/badvim/

Also, it’s best to just have one instance of Vim running, in server mode, so you can send files to it from the command line.

Why would you not just set the location of the backup and swapfiles to a fixed place in your system?

Try this:

    set backupdir=~/.vim/backups,.
    set directory=~/.vim/swapfiles,.
It will only write in the current directory, if ~/.vim/backups does not exist, and the dot is just there for portability, so nothing breaks when using my vimrc on a new system.

Edit: Upon actually reading your blog-post, I understand at least one reason - my options may not change the behaviour of a file not being written to the correct inode, so you have a point for some build systems.

I actually learned rather much reading this, thank you for sharing!

You should end your swapfile directory setting with two slashes, i.e.:

  set directory=~/.vim/swapfiles//,.
From the help text for "directory":

> For Unix and Win32, if a directory ends in two path separators "//", the swap file name will be built from the complete path to the file with all path separators replaced by percent '%' signs (including the colon following the drive letter on Win32). This will ensure file name uniqueness in the preserve directory.

In fact, I think your idea is better, and I’ll probably switch to doing that some day, just in case one of these files turns out to save me.

Edit: Hmmm. I’ll have to think some more about it. Anyway, glad you found my witeup useful.

I laughed at the poetry of the line "I don’t really want Vim to litter my filesystem with all of these piles of nervous energy."


I was still thinking about this today. "I have all these receipts everywhere..."

I’m glad this made an impression in you! (I know what you mean about the receipts.)

Persistent undo is one of the best features in Vim. On any permanent working environment, I would definitely enable it.

My undo files are in ~/.cache/

I have a .vimrc I set up a decade or so ago. I can't remember what's in it, just that I have to comment out a few lines every time I copy it from a Mac to Linux or vice versa.

In retrospect, I probably should have just gotten used to whatever the default is, because using Vim without my .vimrc doesn't actually feel like Vim to me.

> Also, as mentioned below, this is for temporary environments where you read more than you edit.

It might be more convenient to just do a one-time setup of something like "bring your .bashrc, .vimrc, etc. with you when you ssh" [0] (previously discussed on HN [1]).

Personally, I've got a shell script that I just scp over and execute to set up my dotfiles (in a git repo) if they aren't already present on a host, but that may not be an option for some (although I guess I could use sshrc to do that too).


[0]: https://github.com/danrabinowitz/sshrc (note: clone of the original repo, which now 404s).

[1]: https://news.ycombinator.com/item?id=8343469

Very useful thanks. I've already added it in my .vimrc. One more setting that I find really useful is this:

    map <F5> <Esc>:w<CR> :!"%:p"<CR>
Especially since I'm used to running my code with F5 since Delphi

I'm not going to set noswf. However, I run into the problem the writer mentions all the time where I'm opening an already opened file. Is it possible to just switch to the already opened file?

No, because it's open in a different instance. You can use one vim instance for all your editing needs and you'll never see that error again.

And you probably should, because vim is rightfully warning you, that you might lose changes made in the other instance.

Yes, it is (at least on Mac in 2013): https://youtu.be/aHm36-na4-4?t=749

That pretty much looks like what I want. I use VimR on the Mac with its multiple windows as opposed to multiple terminal window and vim. But this is close and I'll see if it work with VimR.

Tastes differ; I would never set 'ignorecase' as a default, and instead of 'number', which is only occasionally necessary and most of the time is visually disturbing, I'd set 'ruler', or a slightly more fancy 'statusline'. The most important one, however, for me is 'set guicursor+=a:blinkon0'.

Usually smartcase does what I want. The only time it doesn't is when I really really want just lower-case characters, but it's a very good heuristic.

Like scooble mentioned, you can add \C to the front of the search to force it to be case sensitive.

I went back and forth with ignorecase until I discovered that placing \c in the search pattern will make that search case insensitive. This makes it much easier to do the odd case insensitive search but keep the default case sensitivity. (\C does the opposite if your default preference is the other way).

In Firefox on macOS, the font fallback to "Apple Color Emoji" is doing really weird things on my machine (like cutting off the top of the number "5").

With that said, thanks for the tips—`set noswapfile` definitely fits my workflow more than not.

Oh wow I had no idea that it looks so bad on Firefox. Thanks for pointing it out, I will look for a fix.

Edit: fixed by removing "Apple Color Emoji" from the list. Thanks!

Kinda derailing the thread but might ask anyway, does anyone got recommendations on dot files synchronization through personal devices? I'm currently using a git+ss repo on a personal server.

I wonder if there are more convenient ways to do this.

I have tried a custom linking script, Ansible, and stow. The best I have found is to just use a bare git repo based off of: https://www.atlassian.com/git/tutorials/dotfiles

The idea is to make an alias that runs git so that it treats your home directory as a git repository and you can directly commit them.

I would recommend bypassing that article's `config config --local status.showUntrackedFiles no` setting and setting a `~/.gitignore`. This way, git will never tinker with your home directory if you accidentally run the wrong command.

So the complete list of setup commands is:

    # Only needs to be done the first time
    cat >~/.gitignore<<'EOF'

    # On subsequent runs
    git clone --bare ssh://git/cfg.git "${HOME}/.cfg"
    function config() {
       git --git-dir="${HOME}/.cfg/" --work-tree="${HOME}" "${@}"
    config checkout -- ~/.gitignore
    config reset ~
    config checkout -- ~
    config submodule update --init --recursive --remote
One caveat is adding files in subdirectories (`~/. config/...`), but just requires changes in your gitignore

Thanks! Using Ansible sounds like a great idea, specially when it allows me to also match installed packages!

Would be great if I could combine with a local secrets engine. Like Hashicorp Vault but local.

Not the simplest way of doing this, but ansible might be an option. IMO the advantage is being able to customize the configuration file depending on the host OS, IP address, attached filesystem, etc.

This is useful because sometimes you want to use the same configuration file on different systems and they usually need some customizations to adapt to each one, which can be done automatically by ansible based on jinja2 templates.

I wrote a program to solve this: https://github.com/knoebber/dotfile/

If I were on a fresh VM with an internet connection and wanted my vimrc, I would do

  curl https://dotfilehub.com/knoebber/vimrc >> ~/.vimrc

I use syncthing to sync a directory, then symlink my dotfiles into place from the synced directory to the location where they are expected.

A few are in a git repo, such as my homedir's Makefile:


I have a shell script that either symlinks dot files from my git repo or writes them. Then I use git normally.

Disabling swap files is smart especially if you edit files directly on a web server using vim. I've found index.php~ and .index.php.swp on a number of web servers over the years.

You can set a few variables to change where these files go:

• 'directory' controls where swap files go, toggled by 'swapfile' (default on), filenames like […].swp; ~/.cache/vim/swap// is a good choice.

• 'undodir' controls where undo files go, toggled by 'undofile' (default off), filenames […].un~; ~/.cache/vim/undo// is a good choice.

• 'backupdir' controls where backup files go, toggled by 'backup' (default off), filename […]~; ~/.cache/vim/backup// is an interesting choice.

Arch Linux actually ships a runtime file that sets these paths, creating the directories if they don’t exist: https://github.com/archlinux/svntogit-packages/blob/packages....

(Note that the double trailing slashes are significant and necessary if you’re using a central location for these files. Refer to the help for explanation.)

I've started writing

    set mouse=""
into all of my Debian server vimrc files so I can still use my middle-click paste buffer over ssh.

I have «relativenumber» but I’ve never touched swapfile. Otherwise I have the same 5. Funny - I often felt vim’s defaults are almost intentionally archaic.

`set confirm` is another great option to turn on all the time. It will save you having to retype a command with the `!` added.

Mine are:

    inoremap jk <esc>
    nnoremap <space> :

nmap ; :

I go with nnoremap but yeah, this is the absolute first edit to my .vimrc

Yes, that's so relaxing for little finger. In fact my minimal vi config is

  :nnoremap : ;
  :nnoremap ; :
  :nnoremap Y y$
  :vnoremap : ;
  :vnoremap ; :
  :vnoremap Y y$

How can you live without f/t followed by ;?

What is the kakoune equivalent of these options?

`hook global RegisterModified '/' %{ add-highlighter -override global/search regex "%reg{/}" 0:+u }` will underline the current search pattern

There is no ignorecase option, `(?i)` is the way to enable that in a regex, you can `map global normal / /(?i)` to auto insert-it

incsearch is the same

`add-highlighter global/ number-lines` display line numbers for all buffers

There is no swap file in Kakoune.

if you're a fan of incsearch, you may also be a fan of neovim's inccommand=nosplit as well.

Holy crap, first 4 lines are cancer! HATE hilight, incremental, very much want case sensitivity, and don’t need wasted space and attention with numbering every line. Current line (and column) in status bar is enough.

No swap file is good though.

Applications are open for YC Summer 2021

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact