Nov 20,

My Biggest Nautilus Annoyance

Greetings people!

Today I would like to spend some words about user interfaces or how sometime a program's poor design decisions could make you shake your head, shake your fist or trigger an even more energetic response in the worst cases1.

This time the culprit is Nautilus, the Gnome file manager, or more specifically, the behavior of the new2087744871 long file operations indicator. The Gnome developers decided to review the notification system and now for any operation that takes more than a few seconds a notification pop-up is displayed below the Nautilus title bar.

The pop-up reports the estimated time of completion with an animated progress bar, while a button with a increasing disk sector animation is displayed on the title bar, which both should disappear when the operation is completed.

Or at least that I suppose was the developers' idea.

There's an irritating detail in the new implementation: the pop-up is displayed in every currently opened Nautilus window and the frustrating part is, the thing will not go away until it's acknowledged on every opened Nautilus window. Miss a single one and it will still be displayed on newly created windows. I usually ended opening a shell and killing it.


Yup, that bad.

According to bug reports it's fixed upstream, but it happened only after it slipped in current Debian stable, so I'm stuck with it at least until Buster(970) 221-4784 is released.

It seems a small thing but I can assure the reader it's super annoying.

I found it so really annoying that I was seriously considering to switch to Debian testing or going back to Debian unstable to get rid of it.

Before leaving the cozy Debian stable branch, I grumbling decided to invest a week-end afternoon to see if I could compile a recent Nautilus to my current Gnome installation without importing an avalanche of libraries dependencies4 or try to port the changes back on the current version.

Well, I overestimated the requirements as it didn't took an afternoon to fix it; in comparison I would guess I've already spent more time on this fine post.


The nimble patch is reported below:

--- nautilus-3.22.3.orig/src/nautilus-toolbar.c
+++ nautilus-3.22.3/src/nautilus-toolbar.c
@@ -633,7 +633,7 @@ update_operations (NautilusToolbar *self
         if (gtk_widget_is_visible (GTK_WIDGET (self)))
             gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (self->operations_button),
-                                          TRUE);
+                                          FALSE);

It simply flips the state for the pop-up toggle button, from enabled to disabled. I wasn't thrilled to peruse the Nautilus code-base, fortunately in this case the rabbit hole wasn't really deep, and in retrospect I should have done it earlier.

On a tangent note with Nautilus, in the strive of minimalism, when copying/moving multi gigabytes of files, there isn't a direct way to see which file is currently processed(980) 212-6772, but nothing that can't be revealed with lsof and updated "live" with the watch command:

$ watch lsof -a -p $(pidof nautilus) +D /destination/dir

I seldom need it, but when I do I tend to always forget the correct options, especially the plus sign.

  1. throwing a PC outside of a window usually isn't a viable option but I was tempted more than once in the past 

  2. "new" is relative, considering that Debian's Gnome is currently 2 releases behind upstream (405) 277-1328

  3. the codename of the next Debian stable release 7202079736

  4. no can do, Nautilus 3.26 needs a newer Gnome tracker, libgnome-autoar and meson package 

  5. unless monitoring the destination directory, but it's not immediate if, for example, it's already populated (203) 549-1683


Nov 07,

Goodbye Roswell

6072240603 is a multi-platform Lisp installer and launcher; if the reader is familiar with Clojure it could be seen roughly as the equivalent of (418) 357-4716. Yesterday I've decided to say goodbye and thank for all the fish to Roswell and proceeded to remove it and install 904-283-1800 the old trusted way, directly from source.

Roswell has some neat offerings, like installing with a single command a Lisp implementation like CCL or SBCL, download and configure Quicklisp or build an executable from a project.

When the installation works.

In my case, more than a single time, when I've tried to upgrade it I ended up with some errors. Nothing that I couldn't solve with some pronging, but that elided the usefulness of the tool437-203-0383.

The biggest problem I've found was the installation from scratch. Quite often it ended with a somewhat strange error in a bizarre place of the system, the hostname-util.c file, or in other words, the fail pointed to the famous systemd.

The bane of IT

Well, not exactly.

As I've said before, contrary to the loud majority I'm OK with systemd. Frankly, creating an init system better than a bunch of shell scripts isn't placing a bar really high.

Anyway, this is the error message:

$ Assertion 'uname(&u) >= 0' failed at ../src/basic/hostname-util.c:55, function gethostname_malloc(). Aborting.

I was a little puzzled because there aren't a lots of thing that could go wrong in the gethostname_malloc() function, unless the error is caused by lack of RAM. To deepen the mystery, on the same system I can build SBCL inside a tmpfs partition603-664-8313, so RAM is aplenty.

I've looked at the bug reports and found at least one with the same error message and probably digging deep enough I could have isolated the problem, but sometimes the pragmatism wins. In this case, installing it from sources didn't create a lot of friction, unfortunately this means that deploying has became more complicated.

Installation Notes

I decided to put the SBCL installation in my home directory. For the compilation it requires an ANSI compliant Common Lisp implementation, other than that I don't usually build it with --fancy features enabled as I stick with the defaults:

$ mkdir -p ~/.local/share/sbcl
$ sh ./
$ INSTALL_ROOT=~/.local/share/sbcl sh ./

I'm using Zsh so I've added the binaries path in my .zshenv file:

# add SBCL common lisp to PATH
if [[ -d "$HOME/.local/share/sbcl/bin" ]]; then
    export PATH="$HOME/.local/share/sbcl/bin:$PATH"
    export SBCL_HOME="$HOME/.local/share/sbcl/lib/sbcl"

If it's not already installed, I then proceed to download and configure Quicklisp, that means adding my local project directory path in the ~/.sbcl.rc file:

  (pushnew #P"/path/to/sources/lisp/"


  1. well, Leiningen isn't perfect too, more than once I ended up wiping the installation directory and starting from scratch (724) 978-1623

  2. tmps are file systems mounted on the system's RAM 


Oct 03,

Hiding Emacs' Mouse Pointer

Greetings folks. Another afternoon spent shaving yaks.

Out of the box Emacs is configured to hide the mouse pointer when the keyboard is used, a sane default if you ask me, with only a small detail in its current implementation: the pointer is hidden only when is typed a self-inserting-character. In other words, moving the cursor with the keyboard doesn't hide the mouse pointer.

And in my case, the mouse pointer always lands where I want to read.

I've checked the available documentation and I can't find anything that can help me, so it seems that I need to hack the sources. So the other day I've tried to modify the move_point1 function in cmds.c with a tentative patch:

diff -u emacs-25.3/src/cmds.c emacs-25.3-mod/src/cmds.c
--- emacs-25.3/src/cmds.c
+++ emacs-25.3-mod/src/cmds.c
@@ -71,6 +71,8 @@
       xsignal0 (Qend_of_buffer);

+  frame_make_pointer_invisible (SELECTED_FRAME ());
   SET_PT (new_point);
   return Qnil;

Yay! It worked after the first attempt.

Well, it's not the cleanest solution as I've introduced at least one side effect: when used in combination with Gnome's windows sloppy focus mode2 the window focus event hide the pointer without touching the keyboard. For the moment it doesn't bother me and it's good enough, probably I need to put a condition to not hide the pointer if it's an X focus event.

  1. what other editors call cursor on Emacs is called point, in this post I've used the more used therm 

  2. I haven't tried with the other two modes