Emacs Context Menu

Howdy folks!

Today I want to talk about the Emacs context menu, or the lack of it on a default install.

Out of the box, when clicking the right mouse button on an Emacs' window in graphical mode nothing happens, well the mouse-save-then-kill function is invoked¹ but it's not what one usually expect. I must admit that sometime I also fumbled with the mouse before reaching for the keyboard, usually when interacting with other applications like web browsers or file managers.

As a side note, speaking of interaction between Emacs and file managers, it never occurred to me that the Dired mode could react to drag&drop actions until I "randomly" copied a file to a currently opened Emacs' Dired window. I was quite surprised to see the file copied to the relative directory.

Try to replicate that vi.

Anywho, this is my take on the context menu in graphical mode:

Well, I didn't want anything fancy, I like to keep things simple; if I'm using the mouse it's probably because I've copied a string from another application and I want to yank/paste² it or the other way around, so that's what I was striving for.

For the interested reader, I'll put all the code below as it's quite minimal:

(global-set-key [mouse-3] 'my-context-menu)

(with-eval-after-load "menu-bar"
  (require 'url-util)

  (defvar edit-popup-menu
    '(keymap
      (undo menu-item "Undo" undo
            :enable (and
                     (not buffer-read-only)
                     (not
                      (eq t buffer-undo-list))
                     (if
                         (eq last-command 'undo)
                         (listp pending-undo-list)
                       (consp buffer-undo-list)))
            :keys "")
      (separator-undo menu-item "--")
      (cut menu-item "Cut" clipboard-kill-region
           :enable (use-region-p)
           :keys "")
      (copy-link menu-item "Copy Link" 
                 (lambda () (interactive) (kill-new (url-get-url-at-point)))
            :enable (and (url-get-url-at-point))
            :keys "")
      (copy menu-item "Copy" clipboard-kill-ring-save
            :enable (use-region-p)
            :keys "")
      (paste menu-item "Paste" clipboard-yank
             :keys "")
      (paste-from-menu menu-item "Paste from Kill Menu" yank-menu
                       :enable (and
                                (cdr yank-menu)
                                (not buffer-read-only))
                       :help "Select a string from the kill ring and paste it")
      (clear menu-item "Delete" delete-region
             :enable (and mark-active (not buffer-read-only))
             :help "Clear region"
             :keys "Del")
      (separator-select-all menu-item "--")
      (mark-whole-buffer menu-item "Select All" mark-whole-buffer
                         :enable (not (= (buffer-size) 0)))))

  (defun my-context-menu (event)
    "Pop up a context menu."
    (interactive "e")
    (popup-menu edit-popup-menu)))

(provide 'context-menu)

That's all.

Testing Buster

Hello random websurfer.

I've started to test the next Debian release on my desktop: codename Buster.

"Buster, the pet dachshund"

I would say that it's reassuringly boring, no major bugs to report in the few days that I've used it, at least from the Debian front.

From the 3rd party providers' front tho, I've found out that Docker CE fails to install even if they have an official Debian Buster repository, no mention on their installation notes of special requirements. After some digging, the reason is iptables was replaced with nftables on Debian Buster and they don't share the same "API" so containerd fails to start and it doesn't complete the upgrade or installation. One possible solution is to invoke update-alternatives to force the "legacy" version:

$sudo update-alternatives --config iptables
There are 2 choices for the alternative iptables (providing /usr/sbin/iptables).

  Selection    Path                       Priority   Status
------------------------------------------------------------
  0            /usr/sbin/iptables-nft      20        auto mode
* 1            /usr/sbin/iptables-legacy   10        manual mode
  2            /usr/sbin/iptables-nft      20        manual mode

Press <enter> to keep the current choice[*], or type selection number:

Another thing that I've noticed, I get the software updates' notifications but I don't get the requester to install them at shutdown time. I haven't yet asked in the IRC channel tho. Also, it seems I can't select the buttons on Gnome Header bars anymore.

About the desktop, at the moment Gnome uses Wayland as default instead of Xorg, I didn't noticed glitches or artifacts, but some minor issues are still present to ruin its prime-time, in my humble opinion.

For starting, it breaks the "focus follow mouse" option or at least it breaks the way I expect it to works. Next it's the title-bar actions, apparently it's missing in the Wayland protocol, in particular the possibility of a window to "lower/upper" itself, as a result clicking a window toolbar with the central mouse button to "lower", as it's configured here, it doesn't work.

Finally, the are some drag&drop issue to and from different application windows, like for example from the file manager to the web browser or the archive manager.

Also, no Wayland Emacs yet. Yeah I know, patches are welcome.

So I reverted to Xorg for the time being.

Speaking of the applications, Flatpak support seems in better shape and the incompatibilities with Debian packages were solved. As a result, I've decided to replace all the desktop applications with their Flatpak equivalent to see if they can be a viable solution. There's the disadvantage of more storage space required as it's not so uncommon to have more that a couple of runtimes installed, but in exchange it would bring applications not tied to the distribution and hopefully sandboxing for increased security¹.

Another drawback is it complicates the devices' access from the application front, in particular devices hot-plug, as it's designed to not provide direct access to dBus for example. To interact with the system from the sandbox in a secure fashion, it was introduced the Portals mechanism, but not all use cases are covered at the moment.

Anyway, I for one, would welcome a full flatpak-ed Gnome.

Bluetooth Mouse Lag

Hello Internauts!

I have a motherboard with an Intel WiFi/Bluetooth combo wireless card so I started to use a wireless mouse again but this time using the internal Bluetooth instead of the usual proprietary receiver that usually wastes an USB port.

I think to understand why the majority avoid Bluetooth as mice protocol.

At the beginning I was quite disappointed, it worked erratically with frequent disconnections, even if I disabled the power-saving option¹ and sometimes, after a disconnection, the mouse wasn't able to connect anymore.

Silly me, I didn't verified if there was a newer firmware for the Bluetooth stack, and yes after installing the latest version the mouse continues to turn itself off, but the update at least seems to have fixed the reconnecting problem and I'm not assuming all the times if the AA battery is depleted.

Another issue that I didn't found out immediately and not firmware related was the pointer horribly lagging when downloading something via WiFi on the LAN.

I tried to search something relevant on-line, but the issue seems a little too generic. At first I thought that being both services, WiFi and Bluetooth, on the same network adapter, maybe it was the result of a resource exhaustion or contention, like bus or the NIC CPU, even somewhat unreasonable with today's multi GHz and multi core CPU*s.

A more plausible hypothesis was a driver bug.

Scouring public mailing-lists and forum messages, I found out an option available on the WiFi Intel driver, bt_coex_active, off by default. Yeah, I somewhat forgot that WiFi and Bluetooth² share the same 2.4 GHz portion of the spectrum.

Shared Medium Coexistence

Coexistence is a somewhat ugly affair because the two technologies use the same medium but quite different protocols. In few words, FHSS (frequency hopping spread spectrum) used on Bluetooth consists on a signal transmitted on a narrow band but constantly "hopping" between different frequencies, while on WiFi is used DSSS (direct sequence spread spectrum) where the available spectrum is divided in bigger chunks of frequencies, so the Bluetooth signal that fall on the spectrum segment used by WiFi is seen as noise that in the best outcome requires packets re-transmission or, in the worst cases, a dropped connection.

Anyway, enabling the option eliminated the lag and I thought the case was closed, unless after a few days I found out that LAN WiFi connection was unbearably slow.

ヽ(´□｀。)ﾉ

Yup, Bluetooth coexistence crippled the WiFi's bandwidth.

Pondering between an unusable lagging mouse or a frustratingly slow WiFi³, by the way I was leaning for the latter, I spotted arguments available with the bt_coex_active option and started to experiment with them. I haven't tried all the combinations, but using the "enable agg TX" parameter it turns out that the bandwidth loss is lower than an acceptable 30% according to a few tests done with iperf3.

So for the moment, I'm satisfied.⁴

For the records, the Intel WiFi card is the Dual Band Wireless-AC 3168 model.