2020-08-28
My divergence from 'proper' Vim by not using and exploring features
I've read a reasonable number of Vim tutorials and introductions by now, and one of the things that stands out is how some of what I do differs from what seems to be considered 'proper' Vim. The simple way to put it is that I use less of Vim's features than the tutorials often introduce. One of the best examples is something that I do all of the time, which is reflowing paragraphs.
The official proper Vim way to reflow paragraphs (based on tutorials
I've read) is gq{motion}
. Often the most flexible version is
gqip
or gqap
(where 'ip' or 'ap' select the paragraph you're
in). Assuming that various things are set correctly, this will
magically reflow your paragraph, much as M-q does in Emacs (a command
I'm accustomed to using there).
However, for various reasons I don't use this; instead I rely on
the general purpose hammer of '!
' and the (relatively) standard
Unix fmt
command. My conditioned reflex sequence of commands for
formatting the paragraph I'm writing is 'ESC { !}fmt }', and in
general I'll use '!}fmt' more or less reflexively.
At one level this is somewhere between a curiosity and a deliberate
choice not to learn all of Vim and try to Vim golf everything in
sight (a choice that I've written about before).
At another level this is kind of a weakness. As an example, in
writing this entry I discovered not just that the gq
command could
be made to use fmt
, but also discovered or re-discovered the ip
and ap
motion modifiers, which might be useful periodically,
including in my usual paragraph reflowing.
Or perhaps not, because now that I experiment with it, using ip
instead of moving to the start of the paragraph causes the cursor
to jump up to the start after the paragraph is reflowed. Using an
explicit { command means that I'm (relatively) conscious that I'm
actively moving before I reflow, instead of having the cursor jump.
If Vim was Emacs, I probably wouldn't mind, but since Vim is Vim I
think I may prefer the explicitness of my current approach.
(And on character golfing, using ip
or ap
saves no characters
in this situation. To really golf, I would need to switch to gq
.)
As before, I probably shouldn't be surprised. Vim's sets of commands and motions are now really quite large, and people generally pick and choose what they use out of large sets like that. I suspect that plenty of Vim users use only various subsets of them, subsets that would strike other Vim users as annoyingly inefficient or old-fashioned.
Firefox 80 and my confusion over its hardware accelerated video on Linux
The news of the time interval is that Firefox 80 is out and in theory it can support hardware video acceleration on X11, not just Wayland (source, also). The master Mozilla tracking bug for hardware accelerated video on X11 is bug #1619523, with all sorts of information. So I downloaded the official release (one of my Firefox setups uses the official builds these days for reasons beyond the scope of this entry) and tried to get it to do accelerated video playback. The short version is that I think I've failed, but I'm not sure why.
Even in Firefox 80, getting VA-API accelerated video playback
requires a whole series of magic incantations in about:config
preferences and perhaps environment variables when you start Firefox
(this may change in the next release). Assuming that all of those
are set right, Firefox can apparently still decide that it doesn't
like your Linux video driver (or its version), your specific hardware,
or perhaps either or both of the resolution of the source video and
the resolution of your display. Some or many of these can be forced
with Firefox settings, but at the same time the bug reports I've
read say that sometimes Firefox ignores hardware acceleration because
it's slower for the specific circumstances, or because it has known
bugs. If Firefox is making a sensible decision for my specific
hardware, that's one thing and I want
it to do what will work best. But if I've missed a setting or if
Firefox is just being twitchy about something, I also want to
override it. In general I know my hardware is capable of hardware
accelerated playback of videos at far lower CPU usage than Firefox
manages (on the same videos).
Unfortunately, Firefox won't tell me what it's doing or why, at
least not in a way that I can understand. I've peered into the
depths of about:support
, which tells me some of the 'what' but
not the 'why', and I've tried some of the things from bug #1619523
without success. If Firefox is or isn't going to do hardware
accelerated video playback, I wish it would tell me both what it was
doing and why. Otherwise I'm probably going to go on being confused
and annoyed with it.
(I care about hardware acceleration not just because of CPU load but because my perception is that hardware acceleration is necessary to play back a full sized video smoothly without dropping frames every so often. This may be wrong on modern hardware, even on my 4k display.)