Weekly Yak Shaving

Ahoy Emacs aficionados.

I don't know if it's a common experience to other Emacs' users, but often in my daily usage of the programmable editor, I became aware of a missing feature, I take a mental note that I should look into it later and usually I end up forgetting about it.

Rinse and repeat, but this time with a slightly sense of deja-vu.

Anywho, a few days ago, after a lot of postponement, I recalled that I wanted to expose the X's primary selection via a keyboard shortcuts on Emacs. For the non initiated, Xorg¹ traditionally uses two distinct buffers for copy/paste text operations: the "primary selection" and the "clipboard".

In Emacs, from what I know, the only way to paste the primary selection is clicking the middle mouse button. Well, hidden in the documentation there's the gui-get-primary-selection function, but strangely it doesn't work when invoked directly with a shortcut. It's not a big deal, but that's probably the reason why I wasn't bored enough to fix it yet.

So nothing earth shattering, it's only a wrapper and it's not going to increase my productivity tenfold, but it was a pet peeve of mine. For the interested reader:

;; paste X primary selection
(defun yank-primary-selection ()
  (interactive)
  (insert
   (gui-get-primary-selection)))

(global-set-key (kbd "C-c C-y") 'yank-primary-selection)

Unfortunately, outside Emacs there isn't a common easy way to access the primary selection without applying brittle hacks like, for example, simulating a middle mouse button click sending the corresponding X11 event and this ignoring Wayland² completely.

A little digression

I suppose for consistency with other desktops/operating systems, Shift-Insert is configured to paste the copy buffer and this is honored, I think, in all the applications I use, except for Gnome Terminal. In Gnome Terminal Shift-Insert paste the primary selection.

I tried in the past to add Shift-Insert to the default Control-Shift-v in the Gnome Terminal as a workaround, in other words having two shortcuts for the same action, but I doesn't seem to work. I tried to define an array with gsettings with the two bindings but only the first element of the array seems to be evaluated.

Bummer.

Another little digression

My default keyboard³ has a spare key in the top left corner, under the Esc key, so long time ago I mapped the "XF86Copy" and "XF86Paste" symbols to it. Unfortunately they aren't supported consistently on all applications as they work with Firefox for example, but I don't recall any Gnome or GTK based application where they do.

In Emacs I've added a couple of bindings, but I used to the traditional yank and kill⁴ shortcuts:

;; adding support for XF86Copy and XF86Paste
(global-set-key (kbd "<XF6Copy>") 'clipboard-kill-ring-save)
(global-set-key (kbd "<XF6Paste>") 'x-clipboard-yank)

To be honest, the configuration is there but I seldom use it.

The Shell

Now, for something slightly related, when using the shell and the result of a command is a single or at most a couple of lines, I can use it as an argument for another command using the following Zsh function instead to reach for the mouse to do a copy&paste:

# quote the last command to reuse output
_insert-last-command-output() {
    LBUFFER+="$(LS_COLORS= TERM=vt220 eval $history[$((HISTCMD-1))])"
}
zle -N _insert-last-command-output
bindkey '^[`' _insert-last-command-output

It's bound to Alt-` in my .zshrc and basically it relaunch the last executed command present in the shell history, with a couple of incantations used to remove colours from the output (a.k.a. ANSI escape sequences), and it injects it the Zsh input buffer. I don't recall where I "borrowed" the idea for the above function, but it has been handy plenty of times.

Finally, the Zsh copy-earlier-word is another pretty unknown little function that I've bound it to Alt-, that I want to throw to the interested reader. It treats the input buffer like a stack and pops out the current inserted words and it also works in the history parameters substitutions.

We should chalk it in the things Bash sorely misses.

VirtualBox, Bluetooth and Suspend: Pick Two

Howdy Interweb neighbor.

I think I've witnessed a bizarre interaction between VirtualBox, Bluetooth and suspend mode on my desktop PC.

Sometimes, very randomly and with intervals between manifestations of the bug so long that I couldn't isolate the cause, the desktop is resumed from suspend without a working Bluetooth adapter and with a repeating error about Bluetooth in the kernel logs, but without useful panic or call trace messages.

I concede the above description has nothing bizarre about it, unless I should mention that the error persisted between reboots and also after shutdowns. The only way to restore normal functionality was pulling the power cord from the wall main socket after power-off.

Now, this is a thing one doesn't see everyday!

Other than installing the most recent BIOS, I begun testing every new kernel that mentioned changes in the Bluetooth stack and every time I installed an update it seemed to solve the issue, until after some time the error resurfaced. Before a few weeks ago tho, I never correlated the fact that the bug manifested itself only after I compiled the VirtualBox's I/O kernel module¹

A couple of months have passed without VirtualBox installed and the system has resumed flawlessly dozens of times. I'm not beyond any doubt I've isolated the culprit — I'd need a reproducible way to trigger the bug to be unequivocally sure — but for the moment I'm pretty confident I've removed this issue.

Now I need to explore some other virtualization solution because I don't think this one would be an easy bug to trace and properly fix it as I would guess, from lack of similar reported cases online, an hardware quirk. Also if memory serves me well, it doesn't help the fact that VirtualBox is in a somewhat low "maintenance mode".

Why I use Zsh

Because "glob qualifiers" expansion with numeric sort order it's boss, that's why!

Greetings Netizens.

Today I was confronted with a silly problem, i.e. how to apply a series of patches in order where their name was ending with a numeric index.

For about ten files it's not a task that should deserve a blog post, the default glob expansion is sorted as anyone would expect:

$ for i in {0..9}; do touch foo-${i}; done
$ echo foo-*
foo-0 foo-1 foo-2 foo-3 foo-4 foo-5 foo-6 foo-7 foo-8 foo-9
$

But what would happens when dealing with a dozen or more files?

Well, for the benefit of the unaware reader, the default expansion uses the alphabetical sorting, or better the sorting is based on the lexicographical order of the ASCII/UTF¹ characters encoding, as showed on the example below²:

$ for i in {0..15}; do touch foo-${i}; done
$ echo foo-*
foo-0 foo-1 foo-10 foo-11 foo-12 foo-13 foo-14 foo-15 foo-2 foo-3 foo-4 foo-5 foo-6 foo-7 foo-8 foo-9
$

Not the order that I would like the patches applied.

Bummer, right?

ʕ ಡ ﹏ ಡ ʔ

Well, one possible solution it's suggested in my own example, using a loop with a numeric index, also I'm adding a file existence check before the action:

$ for i in {0..15}; do [[ -f foo-${i} ]] && echo foo-${i}; done
foo-0
foo-1

[...]

foo-9
foo-10
foo-11
foo-12
foo-13
foo-14
foo-15
$

Feasible, even if a little verbose.

I'm sure someone of the Zsh team was bummed too because there's an option called NUMERIC_GLOB_SORT, not set by default tho, that literally states if numeric filenames are matched by a filename generation pattern, the filenames are sorted numerically rather than lexicographically. This means that one has to remember to check if the option is enabled or to apply it with setopt if not.

Can we do better? Sure, enter the glob qualifiers.

٩( ′ㅂ`)و

Briefly, with its qualifiers, Zsh can basically filter the result of a glob expansion, for example *bar*(/) returns a list of all the directories that contains the "bar" string in the current directory³. There is a huge list of qualifiers described on the official documentation and nearly at the end of the page there's the n qualifier which description states it sets the NUMERIC_GLOB_SORT option for the current pattern:

$ for i in {0..15}; do touch foo-${i}; done
$ echo foo-*
foo-0 foo-1 foo-10 foo-11 foo-12 foo-13 foo-14 foo-15 foo-2 foo-3 foo-4 foo-5 foo-6 foo-7 foo-8 foo-9
$ echo foo-*(n)
foo-0 foo-1 foo-2 foo-3 foo-4 foo-5 foo-6 foo-7 foo-8 foo-9 foo-10 foo-11 foo-12 foo-13 foo-14 foo-15
$

Neat, isn't?

Keybind of the Day

Not strictly related to the above, but I've recently found out that on Zsh there's a function called _most_recent_file bound as default to "Ctrl-x m". I think I've always had a couple of aliases on my .zshrc to list the last modified file or directory using — guess what — glob qualifiers⁴, but this is way better as it can select the most recent file and also expand a glob. For example cat *.py followed by "Ctrl-x m" would insert in the edit buffer the name of the last Python file modified in the current directory, even if more recent files are present.