No serious user of Vim would ever suggest that you not customize it. It's worth knowing the basics of a stock Vim configuration for simple use cases on a new system or in an environment where you can't or don't want user config, but if you're writing software all day in a stock Vim configuration, you're a masochist or a fool.

The advice I’ve followed is that when customizing vim, you should try to only extend it, not modify existing behavior. For example, in development it’s very useful to have a fuzzy finder. On a server, I won’t need it, and even if I reflexively did the shortcut to open it, nothing would happen. Same goes for things like linters, syntax highlighters, global search tools etc. Priceless on your primary dev machine, but you’re not completely hobbled without them.

I think the same applies to the pedal. Maybe you’ll try to use it when it isn’t there, but so what? It might slow you down for a second, but I don’t think it’s going to be a major inconvenience.

As a beginning VIM user I started out with the stock keybindings idea. After using it for nearly a decade, my finding is that it's like learning multiple spoken languages. It's not hard to switch context and use vanilla VIM despite normally using lots of customization. But, I do try to keep things idiomatic and predictable and not override frequently used key bindings.

This has been my experience as well. My vimrc is full of little niceties that I could live without, but if I end up in a vim without my shortcut keys I'd be like 'Oh this again I guess I have to :bn :bn instead of <C-q><C-q>'

I haven't really forgotten any of the long form commands that I create shortcuts for, but it's really annoying using the long forms when typing them out over and over was the reason why I created shortcuts for them in the first place...

> No serious user of Vim would ever suggest that you not customize it.

My .vimrc has the following lines:

    source /usr/share/vim/vim80/vimrc_example.vim

    colo desert256

    set ai
    set et
    set sts=4
    set sw=4
    set t_Co=256
    set ts=4

On systems that I don't have my .vimrc on, I have no problem working with them because what's in /etc/vimrc works well enough for me since I really don't have to much to change other than the colorscheme (since vim mode lines take care of the rest).

Yes, and this is the trouble with vim -- everyone needs to customise it, and that makes it difficult for the community to have standarised ways of doing things.

Everyone has their own workflow preferences and some will prefer using a lot of custom abstractions in their work environment. Others may apply a very minimal set of customizations (if they bother at all).

I believe it's better to allow people to choose how they configure their editor rather than making that decision for them.

But it would be better if the default configuration was good enough for most people.

Instead, Vim has a very spartan default configuration. There are good historical reasons for this. But it is a sad history, because it means, most long-time users end up with fairly heavy customisation. And those customisations will routinely be different from everyone else's set up, not just when they want to enact some personal preference.

That's true, I have more customizations to vim than I can count, however the idea that someone had tried to convey to the parent was probably not that he shouldn't customize it, but that he should remain idiomatic. I don't, for example, change the functionality of common keys, as I need to use them when I'm on an environment that's not my computer. Instead, I add functionality that didn't exist before or change defaults to my preferred settings. If I do change a key, it's a key I will never use, like caps lock.

When I'm much older, or, for dramatic effect, perhaps on my death bed, I hope someone asks me what the most important event of my life was, or what my fondest memory is, that sort of question.

I'm going to tell them: "Remapping caps lock to delete".

Not in Vim, but system wide.

Interesting. I mapped mine to ESC but I can see that being equally useful. Usually when deleting, I leave insert mode and use `d` or `x`.

I should have said: I don't use Vim at all. I get by with Notepad++ for the tiny amount of G-Code editing I need to make a few tweaks to laser cutter programs.

I use AutoHotKey to remap caps lock to delete and shift + caps lock to caps lock.

Years ago, I got into the habit of using ctrl-[ to get out of insert mode instead of pressing Esc. I find having CapsLock useful for typing all-caps constants in source code when needed.

I map CapsLock to Ctrl, where it belongs. I've recently gotten into the habit of using Ctrl-[ for Escape, though, because I'm stuck on a MacBook with one of those horrible touchbars, and I had to turn it off to remain sane.

Can't think of a good reason to type out constants.

Don't vim have decent autocomplete?

(I mostly use it when ssh-ing into servers but figured people who code in it must have set it up as an IDE?)

> Don't vim have decent autocomplete?

It does, but it requires that the word to be autocompleted is present in one of the other loaded buffers. If you're typing out a new variable name, it won't work.

So it doesn't take libraries into account?

I was referring to the regular complete feature (rather than omnicomplete). The default setting is supposed to take included files into account, but that feature doesn't appear to work with imports in python.

Not unless you use a plugin like YouCompleteMe

Question for anyone who knows: is there a vim command or plugin to transform the word the cursor is under to upper/lowercase (or camelCase, kebab-case, snake_case, while we're at it)?

g~w will swith lowercase letters to uppercase ones and vice versa. gUw will change all letters in the word to uppercase. guw will change all uppercase letters in the word to lower case. See :help case for more details.

There are probably plugins to change words to camelCase, snake_case, etc, but I'm not aware of any built-in command to do that (other than manually editing it).

I went with ctrl-[ for a bit and still do use it when I use another computer, but I find caps = esc to be so much more relaxing for the fingers.

I believe all the goods of Vim comes from lightness and portability. There are plenty of Vim emulators on other editors. Emacs for example are ricer's heaven.

What is the meaning of "ricer's" in this context?

The only thing that springs to mind is 'Racing Inspired Cosmetic Enhancements'.

Ricer is a slang term for a supped (souped?) up/tricked out Japanese car, usually with lots of aftermarket parts which make it go faster than stock. Think civics and supras.

He’s making an analogy between those cars with tons of modifications and the extent of customization that seems common in emacs.

Yes, we're talking about the same thing.

See https://www.urbandictionary.com/define.php?term=rice

Race Inspired Cosmetic Enhancements. (R.I.C.E.)Parts put on cars to make them look fast, when they have no internal tuning, and are actually slow as hell. Parts usually consist of excessivley angular bodykits, large rear spoilers, neon, sponsor stickers, chrome rims, fake "coffee can" exhaust tips, and loud, annoying paint jobs and/or vynils. Sometimes parts are do-it-yourself installed and are basically duct taped to the car. Most commonly known for being done to Honda Civics, but can also be done to slow domestic vehicles, such as a Chevy Cavalier, etc.

In the common vernacular where I live it's generally meant as a pejorative.

I'm pretty sure that's a backronym and that "ricer" is a contraction of "rice rocket," i.e. a pejorative and slightly racist term for performant asian automobiles.

That sounds pretty likely.

I’ve been using Vim as my primary text editor for 9 years and i soon decided not to maintain a vimrc shortly after I began using Vim because I use a lot of different conputers here and there. That has worked out perfectly fine for me.

OTOH I’ve been using the Dvorak keyboard layout and custom keyboards for the same period of time but usually I get by if I need to type just a little and if I need to type a lot I bring one of my keyboards.

By other computers you mean SSHing to them or working at them physically? If the latter, this sounds like a very odd excuse. If you use a custom KB layout on your main machine(s), it is a way bigger showstopper for being effective at the rest of them. As you said, you do not care about those other machines much, so why stint yourself and not use handy customizations at least on the main computer?

I suffer from this "phantom clutch syndrom" myself. Slowing smoothly to a stop and SLAM full on panic stop because I pressed the brake to the floor with my left foot.

I broke the (foot activated) parking break or my wife's old car by doing this...slamming on it like it was a clutch. She's never let me live that one down.

I've been driving manual transmission vehicles for around 25 years at this point. It's gotten to the point that when I drive a vehicle with an automatic transmission, I'll actually use the parking brake to hold it in place when stopped at a traffic light (while the car is in neutral). Before I start, I'll put the car into drive, release the parking brake and then press the accelerator to start moving. With a foot operated parking brake, it's sort of like using a clutch when starting :)

Bit of a tangent we're on here, but I wonder if HN disproportionately drives stick.

Many Europeans here I guess.

Automatic is frowned upon by many of us ;-)

Yes, people with automatic licenses are a running joke!

I guess when electric takes over that's all we'll have. I'll miss manual gears for sure.

New car has a CVT. I really wish it had a gear ratio "throttle" control, making it a manual (but no need for a clutch).

You can put your custom .vimrc online somewhere (like Github) and download it to new computers with wget. For quick edits on someone else's computer, using plain Vim isn't much trouble though.

I typically use vi for quick edits on servers and other developers computers.

That is is what drives me away from novel input methods and over-configured setups in general. On one hand it feels silly, but it feels a lot worse to be bewildered by a default setup.

Who is bewildered by a default setup, though? I think this is a ridiculously implausible straw man.

Ask any long-time DVORAK user and they'll tell you how hard it is when faced with a standard QWERTY.

I've used Dvorak as my primary layout for ~12 years now, and I'm just as capable at typing on QWERTY. Colleagues object if I set servers and test machines to a different keyboard layout.

The biggest struggle is words beginning "am" or "ma", the two keys which are in the same location on both layouts.

If you can learn to cope with changing between a Mac and non-Mac then you can learn to cope with changing keyboard layouts.

I'd recommend using only one layout when learning though: I switched solely to Dvorak when I was learning, then learned to use both side-by-side afterwards.

I know 5 long-time Dvorak users including myself and none has significant trouble using qwerty.

It's also very uncommon to have to type on somebody else keyboard (and not good for hygiene).

Perfect example, exactly why I don't use dvorak despite hearing its praises constantly. We live in a qwerty world.

I use Dvorak, and it's only once a month or so that I type more then two words on a Qwerty keyboard.

If I'm helping a colleague, I expect them to type, otherwise they probably won't remember anyway. Otherwise, all I'm likely to type is a couple of letters to search for a name on the video conferencing system or a YouTube video on a friend's computer.

Can I ask how long did it take you to be touch typing on dvorak and how would you describe the benefits?

I like the idea of 'better' input methods including key layout but in reality I've found it simpler to stick to the defaults of the world. I'd be interested to hear your experiences

I learnt during the summer after the first year of university, when I was working on a small summer project at the university. It can't have been more than two months, probably more like one. I didn't touchtype Qwerty, although I could type fairly fast while looking at the keyboard.

I made the "tent" showing the keyboard layout, as described at [1].

It's simply more comfortable to use Dvorak. The clearest way I have to show that is by tapping fingers on the table: it's much easier to go small-to-large than large-to-small. On Dvorak, that means typing digraphs like sn, st, sh, nt, nh, th is optimized (Qwerty equivalent: ;l ;k ;j lk lj kj — what a waste of easy-to-type combinations!). The reverse combinations are rarer in English: ht, hn, hs, tn, ts, ns.

All the rare letters are on the bottom row, so the most awkward movement — bottom row then top row — is minimized.

Added to that, hand alternation is much better, which is also more comfortable. Taking my first sentence, "after" and "was" are all on one hand, and trigrams like "ear" (learnt), "rst" (first), "ect" (project) are common, yet ugly to type on Qwerty.

If you can touchtype Qwerty, type this to simulate typing the first two sentences:

G pdaolk hfoglu kjd ;fmmdo aykdo kjd ygo;k tdao sy flg.do;gktw ,jdl G ,a; ,sovglu sl a ;mapp ;fmmdo roscdik ak kjd flg.do;gkte Gk ialqk ja.d nddl msod kjal k,s mslkj;w rosnanpt msod pgvd slde

To remain closer to the defaults of the world, I've never bothered with Colemak or similar. I can add Dvorak to any computer I use, which I will occasionally do if someone asks me to use their computer to take minutes in a meeting or similar.

[1] http://www.dvzine.org/zine/20-21.html

Thanks for the response! Typing that paragraph in dvorak definitely felt smoother than qwerty. The tent is a good idea for handling the switch, maybe I'll be a convert yet

Fortunately, no one will ever say that's why I don't use emacs despite hearing its praises constantly. We live in a vim world (or vice versa). :)

I used a vim config that was intuitive to me and that I loved before I used much of default vim and that's exactly how I felt... so...

Huh, that's completely opposite to my experience. Sure, I miss some niceties, but I can't say that I am anywhere close to baffled or confused by a default setup.

Your experience is unsurprising. It depends on how much time you spend in a default configuration and how disparate your config is to that default.

I have no qualms using default vim despite it not being my standard method of work, but I still hate the feeling of any case where some muscle memory sequence does not result in what I expect. Ideally I don't want to have to think about anything outside of the problem at hand at all, and this is exactly the kind of thing that breaks immersion.

Because of this, among other reasons, I like small configs, standard input methods, programs with sane defaults and having a simple dotfiles repo.

On this note I can't wait til the next best set of standard input/output comes along, like AR screen so we can move around freely and naturally while working... that's the dream

I hate how different vim behaves on Debian compared to other distros.

Right click paste? Nope. On Debian it changes to visual mode.

> On Debian it changes to visual mode.

If you put this in your .vimrc, it should allow you to paste from the system clipboard by pressing space-p:

    let g:mapleader = "\<Space>"
    nmap <leader>p "*p
    vmap <leader>p "*p

(Or use `"*p` or `"+p`, not including the backticks.)

That will only work if the xterm_clipboard feature is enabled at compile time with vim.

Edit:

s/clipbaord/clipboard/

Oh, I'm not sure how it works on regular Debian. I'm using Ubuntu and it works out of the box here. I'm using neovim now, but it works with regular vim from the package manager too.

You can try running:

    :version

within vim to see what compile time features are enabled or disabled. If the list says +xterm_clipboard, then that feature is enabled.

In my experience, terminal vim doesn't have that feature enabled, but gvim does.

I've always used the + register to copy or paste text in vim (if X11 is enabled). Otherwise, I'll use xclip to handle interfacing with the clipboard.

    :w !xclip -selection clipboard

or

    :r !xclip -o -selection clipboard

Hmm. I don't think that works over ssh?

You may have to use the -display parameter though the man page for xclip says that it will use the value of $DISPLAY by default. You will also need to enable X11 forwarding over ssh with the -X parameter or with the ForwardX11 option in the ssh config file.

This has nothing to do with what distro you are using, except perhaps what termcap information it has. If vim detects that the terminal can support mouse input, then it will enable mouse features. If not, vim does not get control over mouse input and your terminal provides default mouse behavior (right-click paste). You can disable mouse features with the command ":set mouse -=a". If you're pasting into vim from a terminal, you may also be interested in the "set paste" command.

That seems unrelated to vim. Doesn't it depend on your terminal if right click will paste? Try Shift right click and see if it pastes like you expect.

But it works fine in Ubuntu. I am SSHing into both and they behave differntly.

This is a recent misfeature. The solution is set mouse=""

Thanks!

I use Vim on Debian Testing, and right-click paste works fine on Gnome Terminal and Konsole, but does visual mode like you find in Xterm or UXterm.