Pretty much likewise. Actually, I do away with the tabstop=4 these days too -- I've grown to like 8-width tabs.
When I started using vi on a Sun machine in ~1986 or so, I was an expert at 'edlin' (if there could be such a thing) because it existed on every DOS machine. I learned vi for the same reason: It not only ran on everything, it was pretty much guaranteed to be installed on everything.
I hated it, as I was used to many other 'visual editors' that were modeless, more like emacs. The first Apollo editor was my favorite.
But in those days, installing an editor was a real task, so I went with what was there. Now it's in my fingers.
Although on the (fairly frequent, because busybox) occasion I have to use REAL vi, I'm flustered when I type capital-V to get a visual line buffer...
Yes, this is a good idea, although I'd like to note there is more nuance.
* `encoding` is what vim uses internally -- the way buffers and registers are stored in memory. Default value is latin1 as you mention, but it will also pick up on the $LANG environment variable. It's more effective in general to set that variable than directly tweak `encoding`. (Mine is en_US.UTF-8 due to my locale.)
* `fileencoding` is the encoding for the current buffer on disk, how it will be read and written. It is translated in memory to `encoding`. Thus you can manipulate files in encodings other than the one used in-memory. (Although if encoding was latin1 I'm not sure how well the round-trip would go.)
* `termencoding` is how the buffer will be displayed to the screen and how the user input will be read. Once again, it can differ from encoding, and will be translated.
* `fileencodings` is an ordered list of options to try when opening a file. Default value: "ucs-bom,utf-8,default,latin1" when encoding is a unicode value.
If you were editing Japanese text, for instance, choosing UTF-16 encoding would actually make vim use less memory than UTF-8, and would not affect the fileencoding used on disk either.
The nice thing about these settings (I use the same ones) is that if you're on a machine that's not configured to use them, they take only moments to type.
Other than shiftround, the other three seem rather language dependent (which is why I've cluttered so many files with various vimlines/modelines over the years). Wonder if the editorconfig-vim plugin might be a better compromise "only plugin" approach? Particularly given the growing consensus towards editorconfig across editors.
Every thousand years this metal sphere ten times the size of Jupiter floats just a few yards past the Earth.
You climb on your roof and take a swipe at it with a single feather. Hit it once every thousand years til you've worn it down to the size of a pea.
Same thing but start with the biggest vim config you can find.
I have no idea where it started...I've been pasting those into my .vimrc for perhaps 20 years now, or more. I'm pretty sure I copied it from someone else.
Specifically, I can't tolerate the tab key actually putting a tab character in. And I like four spaces per tab.
I've been using vi[m] on an almost daily basis since about 1989...wow, that's 30 years.
In those decades, I have resisted putting anything in my .vi[m]rc except:
set tabstop=4
set expandtab
set shiftwidth=4
set shiftround
That's it. And I agree with you, it's a very happy place for me.