Wandering Thoughts archives

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.

unix/VimNotUsingFeatures written at 23:59:37; Add Comment

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.)

web/Firefox80VideoAccelConfusion written at 01:17:01; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.