2019-02-17
Why I like middle mouse button paste in xterm so much
In my entry about how touchpads are not mice, I mused that one of the things I should do on my laptop was insure that I had a keyboard binding for paste, since middle mouse button is one of the harder multi-finger gestures to land on a touchpad. Kurt Mosiejczuk recently left a comment there where they said:
Shift-Insert is a keyboard equivalent for paste that is in default xterm (at least OpenBSD xterm, and putty on Windows too). I use that most of the time now as it seems less... trigger-happy than right click paste.
This sparked some thoughts, because I can't imagine giving up middle mouse paste if I have a real choice. I had earlier seen shift-insert mentioned in other commentary on my entry and so have tried a bit to use it on my laptop, and it hasn't really felt great even there; on my desktops, it's even less appealing (I tried shift-insert out there to confirm that it did work in my set of wacky X resources).
In thinking about why this is, I came to the obvious realization about why all of this is so. I like middle mouse button paste in normal usage because it's so convenient, because almost all of the time my hand is already on the mouse. And the reason my hand is already on the mouse is because I've just used the mouse to shift focus to the window I want to paste into. Even on my laptop, my right hand is usually away from the keyboard as I move the mouse pointer on the touchpad, making shift-Insert at least somewhat awkward.
(The exception that proves the rule for me is dmenu. Dmenu is completely keyboard driven and when I bring it up, Ctrl-Y to paste the current X selection is completely natural.)
I expect that people who use the keyboard to change window focus have a pretty different experience here, whether they're using a fully keyboard driven window manager or simply one where they use Alt-Tab (or the equivalent) to select through windows. My laptop's Cinnamon setup has support for Alt-Tab window switching, so perhaps I should try to use it more. On the other hand, making the text selection I'm copying is generally going to involve the mouse or touchpad, even on my laptop.
(I don't think I want to try keyboard window switching in my desktop fvwm setup for various reasons, including that I think you want to be using some version of 'click to focus' instead of mouse pointer based focus for this to really work out. Having the mouse pointer in the 'wrong' window for your focus policy seems like a recipe for future problems and unpleasant surprises. On top of that, X's handling of scroll wheels means that I often want the mouse pointer to be in the active window just so I can use my mouse's scroll wheel.)
PS: Even if it's possible to use keyboard commands to try to select things in xterm or other terminal emulators, I suspect that I don't want to bother trying it. I rather expect it would feel a lot like moving around and marking things in vi(m), with the added bonus of having to remember an entire different set of keystrokes that wouldn't work in Firefox and other non-terminal contexts.
2019-02-12
Using grep
with /dev/null
, an old Unix trick
Every so often I will find myself writing a grep
invocation like this:
find .... -exec grep <something> /dev/null '{}' '+'
The peculiar presence of /dev/null
here is an old Unix trick that
is designed to force grep
to always print out file names, even
if your find
only matches one file, by always insuring that grep
has at least two files as arguments. You can wind up wanting to
do the same thing with a direct use of grep
if you're not certain
how many files your wildcard may match. For example:
grep <something> /dev/null */*AThing*
This particular trick is functionally obsolete because pretty much
all modern mainstream versions of grep support a -H
argument to
do the same thing (as the inverse of the -h
argument that always
turns off file names). This is supported in GNU grep
and the versions of grep
found in FreeBSD, OpenBSD, NetBSD, and
Illumos. To my surprise, -H
is not in the latest Single Unix Specification grep
, so
if you care about strict POSIX portability, you still need to use
the /dev/null
trick.
(I am biased, but I am not sure why you would care about strict POSIX portability here. POSIX-only environments are increasingly perverse in practice (arguably they always were).)
If you stick to POSIX grep
you also get to live without -h
. My
usual solution to that was cat
:
cat <whatever> | grep <something>
This is not quite a pointless use of cat
, but it is an irritating
one.
For whatever reason I remember -h
better than I do -H
, so I
still use the /dev/null
trick every so often out of reflex. I may
know that grep
has a command line flag to do what I want, but
it's easier to throw in a /dev/null
than to pause to reread the
manpage if I've once again forgotten the exact option.
2019-02-02
A little appreciation for Vim's 'g' command
Although I've used vim for what is now a long time now, I'm still
somewhat of a lightweight user and there are vast oceans of useful
vim (and vi) commands that I either don't know at all or don't
really remember and use only rarely. A while back I wrote down
some new motion commands that I wanted to remember, and now I have a new command that I want
to remember and use more of. That is vim's g
command (and with
it, its less common cousin, v
), or if you prefer, ':g
'.
Put simply, g
(and v
) are filters; you apply them to a range
of lines, and for lines that they match (or don't match), they then
run whatever additional commands you want. For instance, my recent
use of g
was that I had a file that listed a bunch of checks to
do to a bunch of machines, one per line, and I wanted to comment
out all lines that referred to a test machine. With g
, this is
straightforward:
:g/cksvm3/ s/^/#/
(There's a whole list of additional things and tricks you can do
with g
here.)
Since I just tested this, it's valid to stack g
and v
commands
together, so you can comment out all mentions of a machine except
for one check with:
:g/cksvm3/ v/staying/ s/^/#/
This works because the commands run by g
and v
are basically
passed the matching line numbers, so the v
command is restricted
to checking the line(s) that g
matched.
There are probably clever uses of g
and v
in programming and
in writing text, but I expect to mostly use them when editing
configuration files, since configuration files are things where
lines are often important in isolation instead of as part of a
block.
Vim (and vi before it) inherited g
and v
from ed
, where it
appears even in V7 ed
. However, at least vim
has expanded them
from V7 ed
, because in V7 ed
you can't stack g
and v
commands
(a limitation which was carried forward to 4.x BSD's ed
).
(Amusingly, what prompted me about the existence of g
and v
in
Vim was writing my entry on the differences between various
versions of ed
. Since they were in ed
,
I was pretty sure they were also in Vim, and then recently I had a
use for g
and actually remembered it.)