Stop, Start

Well, here we go again, again. Having stalled out back in 2013 to restart in 2015, I stalled out again in 2017, so am finally restarting seven years later. Again. I do have a dozen or more half-written posts from that period that may leak out slowly, in backdated form.

The stack for the blog has been updated again, naturally – the tools got better after all. So now this is using Zola with, initially, the abridge them](https://github.com/jieiku/abridge/). I think it’s shinier, and hopefully also involves (almost) no JavaScript, is finally accessible, and not too heavyweight. In removing the excessive JavaScript, I also updated my publication list generation process: no more CoffeeScript and JavaScript, just some plain ol’ Python using the slick new uv tooling. The Justfile incantation is something like:

papers := "../templates/shortcodes/publications.html"
bibinputs := "../papers/bibinputs.json"

# build papers data for site
@papers:
  cd bib2html && uv sync && uv run -- ./src/bib2html {{bibinputs}} >| {{papers}}

I’ve also added a register of interests so I stop having to scrabble around remembering what I’m officially doing when I’m occasionally asked.

The stack underneath has also changed. I finally kicked the Mac OS habit after over 10 years – decided I’d had enough of Apple hiding things and generally getting in my way – at the same time I switched from Android to iPhone. Never do things the easy way, that’s my motto. So now I’m back on a PC … but it turns out that 2024 (well, 2023 in fact) is the year of Linux on the Laptop for me. Not something I thought would actually happen when we joked about it in the late 90s. Truly, times change. And not just any old wannabe-Windows distribution but the resolutely idiosyncratic and copiously yet poorly documented NixOS using Flakes and Home-Manager of course, with Wayland and Sway. I’ve even finally made the leap to Codium, the de-Microsofted version of VSCode, from Emacs (mostly – org-mode has not yet been replaced). I blame Andrew and Chris.

For the terminally curious, this meant a fairly heavy reworking of my 30 years old dotfiles – still work in progress but adequately organised for now I think. See the NixOS specific bits if curious.

And, because I’m going to try to include at least one vaguely technical bit (or at least, one bit which isn’t just me bemoaning that I haven’t written anything in years), I confess to being particularly pleased with the following fragment to enable my Sway startup script to start several apps on particular workspaces, by switching to the workspace, starting the app, and then waiting for a suitable window to appear. The latter step entails

• subscribing swaymsg to window messages with jq to extract the messages of interest indicating a new window in the background,
• executing the command to start the app,
• using grep/pkill in tandem to kill the subscription when the new window is detected, and finally
• waiting for the subscription to have been killed.

It seems fairly (indeed, surprisingly) reliable.

wait_for () {
  { swaymsg -r -m -t subscribe '["window"]' |
    jq -c --unbuffered '. | select(.change == "new")' |
    { grep -m1 . >/dev/null ; pkill swaymsg ;} &
  } 2>/dev/null
  pid=$!
  swaymsg -- "exec $*" && sleep 0.5
  wait $pid 2>/dev/null
}

Use via something like:

wayland.windowManager.sway.config.startup =
  let
    msg = cmds: "swaymsg '${builtins.concatStringsSep ", " cmds}'";
    workspace = ws: msg [ "workspace --no-auto-back-and-forth ${ws}" ];
    after = delay: cmds: "sleep ${toString delay} && ${msg cmds}";
    startup = pkgs.writeShellScriptBin "startup.sh" ''
      wait_for () {
        { swaymsg -r -m -t subscribe '["window"]' |
          jq -c --unbuffered '. | select(.change == "new")' |
          { grep -m1 . >/dev/null ; pkill swaymsg ;} &
        } 2>/dev/null
        pid=$!
        swaymsg -- "exec $*" && sleep 0.5
        wait $pid 2>/dev/null
      }

      ${workspace "${mediaws}"}
      wait_for "rhythmbox"
...
    '';
  in
  [ { command = "${startup}/bin/startup.sh"; } ];