stumpwm on The Neo-Babbage Files

Group-agnostic previous-focussed-window memory in StumpWM

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Sat, 25 Apr 2020 14:25:00 -0500

I’ve started using StumpWM’s groups (like “workspaces” in other window managers) more extensively, but this broke a behaviour I like: the ability to easily switch back to the last focussed window, because StumpWM’s “last focussed” is group-specific. So I wasn’t easily about to switch quickly back and forth between two windows that were inb different groups, which turns out to be something I frequently want to do (e.g. switch back and forth between an emacsclient frame in my “emacs” group and a Firefox instance in my “web” group).

Here’s my fix [updated with some fixes on [2025-01-27 Mon]]:

;; Global 'last focussed window'
(setf *global-ante-earlier-focussed-window* 'nil)
(setf *global-earlier-focussed-window* 'nil)
(setf *global-prev-focussed-window* 'nil)
(setf *global-cur-focussed-window* 'nil)

(defun panrecord-of-last-focussed-window (currwin lastwin)
  "Record last visited windows and their group."
  (unless (or (search "*EQUAKE*[" (window-name currwin)) ;; don't record Equake
              (equal (cons (current-window) (current-group)) *global-cur-focussed-window*))
    (when (find-window-globally
           (car *global-earlier-focussed-window*) (screen-groups (current-screen)))
      (setf *global-ante-earlier-focussed-window* *global-earlier-focussed-window*))
    (when (find-window-globally
           (car *global-prev-focussed-window*) (screen-groups (current-screen)))
      (setf *global-earlier-focussed-window* *global-prev-focussed-window*))
    (when (find-window-globally
           (car *global-cur-focussed-window*) (screen-groups (current-screen)))
      (setf *global-prev-focussed-window* *global-cur-focussed-window*))
    (setf *global-cur-focussed-window* (cons currwin (current-group)))))

(defun find-window-globally (window group-list)
  "Check for presence of window in all groups."
  (if (equal (car group-list) 'nil)
      'nil
      (if (member window (group-windows (car group-list)))
          window
          (find-window-globally window (cdr group-list)))))

(defcommand switch-to-last-focussed-window () ()
  "Switch to last focussed window, irrespective of which group it is in and what group we're currently in."
  (progn
    (if
     (and
      (not (equal *global-cur-focussed-window* *global-prev-focussed-window*))
      (or
       ;; we're in the same group [same logic below]
       (equal (car (screen-groups (current-screen)))
              (cdr *global-prev-focussed-window*))
       ;; or we can switch to the previous group
       *global-prev-focussed-window*))
     (progn
       (switch-to-group (cdr *global-prev-focussed-window*))
       (focus-window (car *global-prev-focussed-window*) t))
     (if
      (and
       (not (equal *global-cur-focussed-window* *global-earlier-focussed-window*))
       (or
        (equal (car (screen-groups (current-screen)))
               (cdr *global-earlier-focussed-window*))
        *global-earlier-focussed-window*))
      (progn
        (switch-to-group (cdr *global-earlier-focussed-window*))
        (focus-window (car *global-earlier-focussed-window*) t))
      (if
       (and
        (not (equal *global-cur-focussed-window* *global-ante-earlier-focussed-window*))
        (or
         (equal (car (screen-groups (current-screen)))
                (cdr *global-ante-earlier-focussed-window*))
         *global-ante-earlier-focussed-window*))
       (progn
         (switch-to-group (cdr *global-ante-earlier-focussed-window*))
         (focus-window (car *global-ante-earlier-focussed-window*) t))
       (message "No window to switch to."))))))

(add-hook *focus-window-hook* 'panrecord-of-last-focussed-window)

;; my binding; set as you will
(define-key *root-map* (kbd "s-f") "switch-to-last-focussed-window")

The unless statement in panrecord-of-last-focussed-window prevents my drop-down terminal Equake “window” from “counting” for history tracking purposes.

The switch-to-last-focussed-window function essentially just switches to the last focussed window, after making sure it still exists. (If not, switch to the window which was focussed before that one, or the one before that one, or else don’t switch and display message indicating this to the user.)

The last line, (define-key *root-map* (kbd "s-f") "switch-to-last-focussed-window"), means that I can double tap s-f (since my StumpWM prefix key is set to s-f with (set-prefix-key (kbd "s-f"))) to switch to the last focussed window, no matter which group it belongs to.

I continue to really enjoy the power that StumpWM’s Common Lisp underpinnings provides the user!

Running pdfpc in StumpWM

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Mon, 29 Jul 2019 15:27:00 -0600

pdfpc is a fantastic application for presenting PDF slides, including perhaps especially those produced using LaTeX Beamer. It creates two (full-screen) windows, one a presenter viewer which shows the time elapsed and a preview of the next slide, and one the presentation view which is what is shown to the audience. It also has a bunch of other cool features like being able to draw on slides; highlight areas of slides, &c.

Here is an example, with the presenter’s view shown on the left; the audience’s view on the right:

In many environments pdfpc is pretty smart about getting the presentation view to the external display, but in StumpWM both end up getting created in the same frame in the same display.

(General tip: in StumpWM, after connecting/activating an external display, you may need to run refresh-heads to get StumpWM to display things properly.)

For whatever reason, I can’t get any of the Screen-related things in StumpWM to behave like I have more than one screen. E.g. *screen-list* shows a singleton list even when an external display is connected and activated:

STUMPWM> *screen-list*
(#S<screen #<XLIB:SCREEN :0.0 1366x768x24 TRUE-COLOR>>)

A passable solution is to use define-frame-preference, adding the following to your init.lisp StumpWM configuration:

;; pdfpc rule - for 'Default' group
;;  move to frame '1';
;;  non-focussing ('nil) the presentation view;
;;  not only matching (t) the target-group ('Default');
;;  moving the 'pdfpc' 'presentation' window
(define-frame-preference "Default"
  (1 nil t :instance "pdfpc" :role "presentation"))

This should properly move the presentation window to the external display when pdfpc is run.

Guix, Nix: You are in a maze of twisty little $PATHs, some undefined

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Wed, 24 Jul 2019 00:48:00 -0600

Some notes on interactive fiction/text adventure games and PATHs in Guix, and StumpWM.

Maze no. 1

There may (likely is) some way of programmatically setting the X Windows PATH variable in Guix System (née GuixSD) via the base configuration (e.g. config.scm), but I haven’t been able to uncover anything that works. This is relevant for being able to use locally installed static binaries or local shell scripts via the window manager.

As a window-manager-specific workaround, in StumpWM, one can programmatically set PATH variables via (setf (getenv "VARIABLE_NAME") "variable-value"). Thus, if you store local static binaries and shell scripts in ~/bin, the following (which you could include in StumpWM’s init.lisp) will add that to your PATH variable:

(setf (getenv "PATH") (concat "/home/YOURUSERNAME/bin:" (getenv "PATH")))

I use this with a static Haskell binary greenclip, which adds clipboard functionality to rofi, and with shell scripts that give “pretty names” to Flatpak run commands.

For example, the literate/natural-language-based programming interactive fiction design language Inform7 (which is due to be open-sourced sometime this year) is now conveniently available as a Flatpak. But the run command after installing is flatpak run com.inform7.IDE, which is non-ideal. So I made a simple shell script named inform7 placed in ~/bin:

#!/bin/sh
flatpak run com.inform7.IDE

Maze no. 2

Nix can be installed as a standalone package manage on top of other distros, including Guix System, which is useful for be able to obtain software currently lacking in Guix System (including, ironically, Hugo, used by this blog, which is present in Nix). Packages available in Nix but not in Guix include Gargoyle, a very nice interactive fiction front-end client that supports a number of different backends, including Frotz and Glulxe. One of the benefits of Gargoyle is that it “cares about typography”. However, Nix applications by default seem to have trouble finding/seeing fonts, including system fonts, local fonts, and even fonts installed via Nix.

This can be fixed by (1) setting the FONTCONFIG_PATH and FONTCONFIG_FILE, e.g. in StumpWM this can be done with:

(setf (getenv "FONTCONFIG_PATH") "/home/YOURUSERNAME/.config/fontconfig/")
(setf (getenv "FONTCONFIG_FILE") "fonts.conf")

And (2) forcing Nix to look in the right places by manual specification in ~/.config/fontconfig/fonts.conf, adding right before the final </fontconfig> (as appropriate):

<cachedir prefix="xdg">fontconfig</cachedir>
<dir>/home/YOURUSERNAME/.local/share/fonts/</dir>
<dir>/home/YOURUSERNAME/.nix-profile/share/fonts/</dir>
<dir>/home/YOURUSERNAME/.guix-profile/share/fonts/</dir>
<dir>/usr/share/fonts</dir>

And regenerating the font cache (via fc-cache -fv) [possibly you may need to install Nix’s fontconfig package].

Equake(!) Quake-style overlay console in StumpWM

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Wed, 22 May 2019 22:26:00 -0500

I’ve been alternatively using both KDE Plasma 5 and StumpWM on various machines and have got a working model for using the Equake drop-down in StumpWM.

The StumpWM #'invoke-equake command hides (using StumpWM native hide-window, rather than Emacs’s make-frame-invisible as the latter creates various issues in finding and fetching the Equake window) the Equake frame if it’s the currently active window; it searches through all windows in all groups on the current screen/monitor, and calls emacsclient -n -e '(equake-invoke)' to create an Equake frame if no extant Equake window is found; and if an Equake window does already exist for the current screen, it is yanked into the current group, pulled into the current frame, and unhidden (if necessary).

This seems to work pretty well, though I haven’t figured out how to have StumpWM ‘skip’ the Equake frame when cycling through Emacs windows. (And, of course, having a proper partial height floating Equake window would be ideal.)

EDIT: Here’s a better, more Quake-like set-up, which actually makes use of recently added partial-height floating windows in non-floating groups:

(defun calc-equake-width ()
  (let ((screen-width (caddr (with-input-from-stringp (s (run-shell-command "emacsclient -n -e '(equake-find-workarea-of-current-screen (equake-calculate-mouse-location (display-monitor-attributes-list)) (display-monitor-attributes-list))'" t)) (read s))))
        (desired-width-perc (read-from-string (run-shell-command "emacsclient -n -e 'equake-size-width'" t))))
    (truncate (* screen-width desired-width-perc))))

(defun calc-equake-height ()
  (let ((screen-height (cadddr (with-input-from-string (s (run-shell-command "emacsclient -n -e '(equake-find-workarea-of-current-screen (equake-calculate-mouse-location (display-monitor-attributes-list)) (display-monitor-attributes-list))'" t)) (read s))))
        (desired-height-perc (read-from-string (run-shell-command "emacsclient -n -e 'equake-size-height'" t))))
    (truncate (* screen-height desired-height-perc))))

(setq *equake-width* 1368) ; TODO: programmatically get screen dimensions before Emacs starts
(setq *equake-height* 768)

(defcommand invoke-equake () ()
  (let* ((on-top-windows (group-on-top-windows (current-group)))
         (equake-on-top (find-equake-in-group on-top-windows)))
    (if equake-on-top
        (progn (setf (group-on-top-windows (current-group)) (remove equake-on-top on-top-windows))
               (unfloat-window equake-on-top (current-group))
               (hide-window equake-on-top)) ;; then hide Equake window via native Stumpwm method.)
      (let ((found-equake (find-equake-globally (screen-groups (current-screen))))) ; Otherwise, search all groups of current screen for Equake window:
        (if (not found-equake)          ; If Equake cannot be found,
            (progn
              (run-shell-command "emacsclient -n -e '(equake-invoke)'") ; then invoke Equake via emacs function.
              (setq *equake-height* (calc-equake-height)) ; delay calculation of height & width setting until 1st time equake invoked
              (setq *equake-width* (calc-equake-width))) ; (otherwise Emacs may not be fully loaded)
          (progn (raise-window found-equake)
                   (move-window-to-group found-equake (current-group)) ; But if Equake window is found, move it to the current group,
                   (unhide-window found-equake) ; unhide window, in case hidden
                   (float-window found-equake (current-group)) ; float window
                   (float-window-move-resize (find-equake-globally (screen-groups (current-screen))) :width *equake-width* :height *equake-height*) ; set size
                   (focus-window found-equake)
                   (toggle-always-on-top))))))) ; make on top

(defun find-equake-in-group (windows-list)
  "Search through WINDOWS-LIST, i.e. all windows of a group, for an Equake window. Sub-component of '#find-equake-globally."
  (let ((current-searched-window (car windows-list)))
    (if (equal current-searched-window 'nil)
        'nil
        (if (search "*EQUAKE*[" (window-name current-searched-window))
            current-searched-window
            (find-equake-in-group (cdr windows-list))))))

(defun find-equake-globally (group-list)
  "Recursively search through GROUP-LIST, a list of all groups on current screen, for an Equake window."
  (if (equal (car group-list) 'nil)
      'nil
      (let ((equake-window (find-equake-in-group (list-windows (car group-list)))))
        (if equake-window
            equake-window               ; stop if found and return window
            (find-equake-globally (cdr group-list))))))

;; Set the mouse focus policy;  - :click is best for proper Equake functioning
(setf *mouse-focus-policy* :click) ;; also StumpWM default (I think)

;; Keybindings
;; bind to an appropriate key
(define-key *top-map* (kbd "F12") "invoke-equake")

This is what it looks like:

video link here

Quake-style drop-down terminal in StumpWM

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Tue, 18 Sep 2018 20:45:00 -0600

One thing I’ve missed in StumpWM is a Quake-style drop-down terminal, like what Guake provides (and I have a Lua-one in my AwesomeWM config). It may be that I’m still haven’t fully absorbed the StumpWM-mindset and that I should be doing this a different way. But up until now when I’m using StumpWM I’ve tended to end up with a heap of terminal windows that are a pain to navigate through (I have a run-or-raise command associated with xterm, but it starts from the first xterm window and usually I want the last – something else to figure out how to do). It’s nice to have a ‘working terminal’ that one can quickly summon and dismiss.

There’s a number of issues for creating a Quake-type drop-down in StumpWM (at least based on my current knowledge). The first is fairly easily dealt with - I don’t want more than one Quake terminal around.

run-or-raise will prevent multiple instances from being created:

(defcommand urxvt () ()
  "Start an urxvt instance or switch to it, if it is already running."
  (run-or-raise "urxvt"'(:title "urxvt")))

(I’m cheating here a bit because I’m not quite sure how to handle title-management. I know windows can be retitled, and I initially tried setting the window title in the above function to “quake”, but somehow I ended up also sporadically re-titling other windows as “quake”, so I’ve side-stepped the whole issue by just using urxvt for my drop-down terminal, with my regular terminal being xterm.)

What we want then is a function that toggles our Quake terminal on-and-off: essentially if the current window is not urxvt, then call the urxvt function defined above, and if the current window is urxvt then switch back to the last used window before urxvt was called. The basic thing we need for this is (if (equal (window-title (current-window)) "urxvt").

The trouble is that StumpWM has a nice feature which is similar to doing C-x b RET in Emacs: it essentially switches to the last window used, so it can be a nice feature for switching back and forth between two different windows you’re working in. The function is pull-hidden-other and it is invoked with “prefix prefix”, which for me is s-f s-f (Super+F, twice), but by default is C-t C- (Ctrl+t twice). Why this creates a problem is because our Quake terminal will muck that up because it will often end up being the last used window, and that’s not what I want. I want pull-hidden-other to switch to the last used window that’s not the Quake drop-down.

I tried a number of different things, and this may still not be the best solution, but it works:

(defcommand rxvt-quake () ()
  "Toggle rxvt-quake window."
  (if (equal (window-title (current-window)) "urxvt")   ; if the current window is quake
      (progn
	(other-window)    ; switch back to window quake was called from
	(select-window-by-number *real-other-window*)  ; switch to the 'real' "other-window"
	(other-window))  ; switch back to the original window - this way after quake finishes, the original configuration is restored
      (progn          ; otherwise, if the current window is NOT quake
      (other-window)   ; first switch the current "other-window"
	(if (not (equal (window-title (current-window)) "urxvt")) ; if the current
								  ; "other-window" is
								  ; quake itself, do
								  ; nothing
	    (setf *real-other-window* (window-number (current-window)))) ; otherwise store the window-number of the current other-window
	(other-window) ; switch back to the window originally called from
	(urxvt)))) ; run-or-raise urxvt

So this function indeed checks to see whether the current window is our Quake drop-down terminal. If it’s not, it first switches to the currently last used window with (other-window) and stores the number of this window in *real-other-window* (but only if this last-used-window isn’t itself urxvt - otherwise we’ll sometime end up ‘over-writing’ the actual last-used-window we want to keep). It then switches back to window that was active when rxvt-quake was invoked, and then it calls the urxvt function which either launches a new urxvt (if none currently exists), or raises the currently running urxvt window. Storing the value in *real-other-window* gives us a way to remember what the ‘real’ last-used window should be.

If rxvt-quake is invoked while the Quake urxvt drop-down is the currently active window, then first (other-window) is invoked, switching us back to the window that was active before we called the drop-down terminal, then we switch to our stored window (which was the ‘real’ last-used window before Quake was invoked), and then we switch back with (other-window) to the window that was active when Quake was first invoked.

This way the window configuration that existed before we summoned our Quake drop-down terminal is restored, and pull-hidden-other effectively ignores the Quake drop-drop.

Bind this command to the traditional F12 with:

(define-key *top-map* (kbd "F12") "rxvt-quake")

And you’re got a ‘traditional’ Quake drop-down terminal in StumpWM.

It is a ‘full-length’ drop-down terminal, however. It might be nice to have it be a fraction of the screen like a more traditional Quake drop-down.

Managing emacsclient windows in StumpWM

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Sat, 18 Aug 2018 21:36:00 -0600

I’m still working on getting my GuixSD machine configured, including working on getting familiar with StumpWM – a windows manager written in Common Lisp – which is the desktop paradigm I’ve decided upon for this Lisp-centric machine.

I’m somewhat habituated to (my) AwesomeWM keybindings, which involve the Super key in combination with various other keys, including say s-1 for tag/workspace 1, s-3 for tag/workspace 3, &c., and s-E (i.e. hold Super and Shift and press e) to launch an emacsclient (see below on the Emacs client/daemon configuration). StumpWM could be configured in a somewhat similar fashion (though it doesn’t seem to quite use tag/workspaces in the same fashion), but the ‘tradition’ seems to be to use a prefix, which is by default C-t (that is, hold Control and press t), which is then released and followed with another key or key combination. I don’t really like using Control for windows management since it tends to conflict with bindings in Emacs and elsewhere, so I’m testing out s-F (hold Super, press f) as a prefix (though whether I’ll stick with prefixed bindings or go back to single action bindings, I’m not yet certain).

From browsing other stumpwm configs, I came across a useful bit of configuration:

(defun run-or-raise-prefer-group (cmd win-cls)
  "If there are windows in the same class, cycle in those. Otherwise call
run-or-raise with group search t."
  (let ((windows (group-windows (current-group))))
    (if (member win-cls (mapcar #'window-class windows) :test #'string-equal)
	(run-or-raise cmd `(:class ,win-cls) nil T)
	(run-or-raise cmd `(:class ,win-cls) T T))))

This function can then be used with specific applications, e.g.:

(defcommand run-or-raise-icecat () ()
	    (run-or-raise-prefer-group "icecat" "Icecat"))

The above function leverages run-or-raise-prefer-group to either launch Icecat, if it is not already running, or else focus the Icecat window, and successive calls will cycle through multiple Icecat windows/windows if more than one Icecat window exists. This is extremely useful as it’s much less cognitively-tasking than figuring out which window number Icecat currently is associated with.

This can then be assigned a binding(s) like:

(define-key *root-map* (kbd "W") "run-or-raise-icecat")
(define-key *root-map* (kbd "C-W") "run-or-raise-icecat")
(define-key *root-map* (kbd "s-W") "run-or-raise-icecat")

This means that one first presses the prefix (s-f for me) followed by either W or C-W or s-W (that is, Shift+w, Control-Shift+w or Super-Shift+w) to either launch Icecat or focus/cycle through existing Icecat windows/windows.

Now, the way I typically use Emacs is to invoke it as a daemon (i.e. emacs --daemon) and then connect Emacsclients to this daemon (i.e. emacsclient -c for the ‘windowed’ gtk-application, emacsclient -t in the terminal). However, if we define a parallel function for Emacs, a particular edge-case arises:

(defcommand run-or-raise-emacsclient () ()
		(run-or-raise-prefer-group "emacs" "Emacs"))

This works rather like the Icecat one as long as at least one Emacsclient window exists (so if there are multiple window, successive calls of run-or-raise-emacsclient will cycle through them). However, if no emacsclient is currently open, it will launch an undaemon’ed Emacs (requiring loading the entire init.el), even if/though an Emacs daemon is currently running and thus could be attached to.

At least one solution to this is the following function (with relevant keybindings):

(defcommand decide-on-emacsclient () ()
 (if (equal (run-shell-command "pgrep \"emacsclient\"" t) "")
     (run-shell-command "emacsclient -c")
     (run-or-raise-emacsclient)))

(define-key *root-map* (kbd "s-e") "decide-on-emacsclient")
(define-key *root-map* (kbd "C-e") "decide-on-emacsclient")
(define-key *root-map* (kbd "e") "decide-on-emacsclient")

The above function executes the shell-command pgrep "emacsclient" and evaluates whether the output of that shell-command is equal to the empty string (which will be the case only when no emacsclient is running). Where at least one emacsclient is running, it executes the run-or-raise-emacsclient function defined earlier, focussing/cycling through running emacsclients. Where no emacsclient is currently running, it executes instead emacsclient -c, opening a windowed emacsclient. And the bindings let me press the prefix and then either Super+e, Control+e or simply e to execute this new function.

I also have the following definitions:

(defcommand emacsclient-launch () ()
  (run-shell-command "emacsclient -c"))

(define-key *root-map* (kbd "s-E") "emacsclient-launch")
(define-key *root-map* (kbd "C-E") "emacsclient-launch")
(define-key *root-map* (kbd "E") "emacsclient-launch")

So that if I want to launch a new emacsclient window instead of switching to an existing one, I can do so using one of series of keybindings parallel to the previous set, but with a capital E rather than a lowercase one.

This is working well for me, and is a nice example of the power of using Lisp-based ‘desktop environment’.

Guix: You are in a maze of lispy little passages, (map equal? ′(′all ′alike) ′(′all ′alike))

Benjamin.Slade@fakeEmailToMakeValidatorHappy.com (Benjamin Slade) — Sat, 04 Aug 2018 21:47:00 -0500

So I finally made a serious go of running GuixSD, a GNU Linux distro which is largely built on GNU Guile Scheme (a dialect of Lisp) on one of my machines (one I had actually put together with GuixSD in mind: an X200 Thinkpad, which I Libreboot‘ed and put a Atheros Wi-Fi card in), and, to increase both the quantity and variety of Lisps involved, am trying to use with StumpWM (which is written in Common Lisp).

It’s a fascinating distro, modelled on Nix, but implemented in Guile. It’s not been exactly easy to get running (one of the videos on GuixSD from Fosdem 2017 included the line “[GuixSD] is like Gentoo for grown ups”), in part because its architecture is rather different from what I’ve experienced with other Linux distros, which use different package managers perhaps and sometimes even different libc’s, but generally follow a similar design philosophy. Rather than spreading out configuration across lots of different pieces, GuixSD seems to largely try to concentrate it in specific configuration files which are transactional in that they can be rolled back (and thus the system can be rolled back to known working states).

It is a GNU-blessed distro, and does take the FSF’s hard line (and to my eyes sometimes weird line) approach to software. So no proprietary software is included in the Guix repos, including firmware (and it runs on the linux-libre kernel). That by itself is fine, but it means the state of affairs for Guix-packaged browsers is pretty poor. No Chromium, no Firefox. IceCat 52 is essentially what’s currently available (if IceCat were up to the latest Firefox ESR 60, it might be easier) in terms of browsers which might be considered secure.

This led me to try to use the Nix installer by itself^* to try to install Firefox and Chromium. Sadly, I can’t get Nix’s Chromium to work at all on GuixSD, and while Firefox works fine, I can’t get it to see my locally installed fonts (or other fonts I’ve installed via Nix).

Hopefully at some point Next Browser will be packaged for Guix, to bring in another major component written in (Common) Lisp. And when (if?) IceCat 60 comes out, that will alleviate the pain somewhat. (I was a long-time Conkeror user, and I briefly tried it again in GuixSD, but I’m not certain of its security and uBlock Origin no long works with it, which I believe is why I stopped using it in the first place).

Other interesting Lispy pieces include mcron, a cron which accepts (as well as Vixie cron style, I think) Guile config files. The examples in Guix manual I couldn’t really get to work. But via the help-guix listserv I found that one can put simple guile scripts in ~/.config/cron/job.guile. Working out how to do a ‘run this every N minutes’ was not immediately obvious, but I figured out how to do it, e.g.:

; execute run_me every 5 minutes
(job '(next-minute (range 0 60 5)) "run_me")
; run execute_me every 2 hours
(job '(next-hour (range 0 24 2)) "execute_me")

One of the other great things about GuixSD is that its init manager, GNU Shepherd, is also written in Guile Scheme. I’ve only had a chance to play with it a little bit, but it seems very nice and it’s good to find other innovative init managers (I would mention here also runit and s6) which take very different approaches to systemd (another innovative init, or perhaps init+, but one that creates more problems than it solves in the end, in my experience).

On the Guix package manager itself: I learned the hard way that searching for packages in Guix is really only comfortable within Emacs: so do guix package -i guix-emacs and then do everything else from guix-emacs within Emacs ( M-x guix-search-by-name to search package names by regex; and M-x guix-search-by-regex to search names+descriptions by regex). The results returned by guix package -s .... in a terminal are not very browseable (though I tried valiantly for some time). But if you’re interested in Guix, you’ll likely interested in Emacs anyway.

What I’m trying to build on this machine is something with lots of Lisp. Of course the kernel is still a kernel written in C, as are lots of the other pieces like the terminal &c., but much of the user-facing things: the package manager, the windows manager, the init, the job scheduler (=cron), and (most importantly perhaps) the ‘text editor’ (read: document composer, email interface, irc interface, twitter interface, blog post interface, code editor …) are all largely written in and interacted with using some form of Lisp (Guile Scheme, Common Lisp, Emacs Lisp).

Guix is a bit like Emacs, I think. It’s an incredibly powerful tool with lots of interesting possibilities, but when you start using it you’re presented with an empty screen with little indication of what you can do. I’ll be sticking with it, I think. Now I’ve got to get to grips with StumpWM and figure out how to configure polybar…

[And if you’re curious about why Guix is pronounced like “geeks”, have a look at this post over on my linguistics blog.]

* As well as being the package managers of both of their respective distros, both the Nix and Guix package managers can be used on top of other distros. Nix doesn’t have quite the same hard line approach to software licences as Guix.