2020-09-13
I'm now a user of Vim, not classical Vi (partly because of windows)
In the past I've written entries (such as this one) where I said that I was pretty much a Vi user, not really a Vim user, because I almost entirely stuck to Vi features. In a comment on my entry on not using and exploring Vim features, rjc reinforced this, saying that I seemed to be using vi instead of vim (and that there was nothing wrong with this). For a long time I thought this way myself, but these days this is not true any more. These days I really want Vim, not classical Vi.
The clear break point where I became a Vim user instead of a Vi
user was when I started internalizing and heavily using Vim's
(multi-)window commands
(also). I started
this as far back as 2016 (as signalled by this entry), but it took a while before I really had
the window commands sink in and habits regarding them become routine
(like using 'vi -o' on most occasions when I'm editing multiple
files). I'm not completely fluid with Vim windows and I certainly
haven't mastered all the commands, but at this point I definitely
don't want to go back to not having them available.
(In my old vi days, editing multiple files was always a pain point where I would start reaching for another editor. I just really want to see more than one file on a screen at once in my usual editing style. Sometimes I want to see more than one spot in a file at the same time, too, especially when coding.)
I also very much want Vim's unlimited undo and redo, instead of a limited size undo. There are a bunch of reasons for this, but one of them is certainly that the Vi command set makes it rather easy to accidentally do a second edit operation as you're twitching around before you realize that you actually want to undo the first one. This is especially the case if your edit operation was an accident (where you hit the wrong keys by mistake or didn't realize that you weren't in insert mode), or if you've developed the habit of reflexively reflowing your current paragraph any time you pause in writing.
(There are probably other vim features I've become accustomed to without realizing it or without realizing that they're Vim features, not basic Vi features. Everywhere I use 'vi', it's really Vim.)
Although I'm now unapologetically using vim, my vimrc continues to be pretty minimal and is mostly dedicated to turning things off and setting sensible (ie modern) defaults, instead of old vi defaults. I'm unlikely to ever try to turn my vim into a superintelligent editor for reasons beyond the scope of this entry.
(I do use one Vim plugin in some of my vim setups, Aristotle Pagaltzis' vim-buftabline. I would probably be more enthused about it if I edited lots of files at once in my vim sessions, but usually I don't edit more than a couple at once.)
Rolling distribution releases versus periodic releases are a tradeoff
In reaction to my entry on the work involved for me in upgrading Fedora, Ben Cotton wrote a useful entry, What do “rolling release” and “stable” mean in the context of operating systems?. In the entry, Ben Cotton sort of mentioned something in passing that I want to emphasize, which is that the choice between a rolling release and a periodic release is tradeoff, not an option where there is a clear right answer.
In the Linux world, fundamentally things change because the upstreams of our software change stuff around. Firefox drops support for old style XUL based addons (to people's pain); Gnome moves from Gnome 2 to Gnome 3 (an interface change that I objected to very strongly); Upstart loses out to systemd; Python 2 stops being supported; and so on. As people using a distribution, we cannot avoid these changes for long, and attempting to do so gives you 'zombie' distributions. So the question is when we get these changes inflicted on us and how large they are.
In a rolling release distribution, you get unpredictably spaced changes of unpredictable size but generally not a lot of change at once. Your experience is likely going to be a relatively constant small drumbeat of changes, with periodic bigger ones. Partly this is because large projects don't all change things at the same time (or even do releases at the same time), and partly this is because the distribution itself is not going to want to try to shove too many big changes in at once even if several upstreams all do big releases in close succession.
In a periodic release distribution, you get large blocks of change at predictable points (when a new release is made and you upgrade), but not a lot of change at other times. When you upgrade you may need to do a lot of adjustment at once, but other than that you can sit back. In addition, if something changes in your environment it may be hard to figure out what piece of software caused the change and what you can do to fix it, because so many things changed at the same time.
(In a rolling release distribution, you can often attribute a change in your environment to a specific update of only a few things that you just did.)
Neither of these choices of when and how to absorb changes is 'right'; they are a tradeoff. Some people will prefer one side of the tradeoff, and other people will prefer the other. Neither is wrong (or right), because it is a preference, and people can even change their views of what they want over time or in different circumstances.
(Although you might think that I come down firmly on the side of rolling releases for my desktops, I'm actually not sure that I would in practice. I may put off Fedora releases a lot because of how much I have to do at once, but at the same time I would probably get very irritated if I was frequently having to fiddle with some aspect of my custom non-desktop. It's a nice thing that I got everything working at the start of Fedora 31 and haven't had to touch it since.)