Jelle's Webpage

AGit in Magit

2025-07-01T12:14:00Z

The Guix project recently migrated ¹ all of their repositories to Codeberg ². In order to facilitate making easy pull requests from the comfort of Magit and Emacs, I've adapted the following Emacs Lisp snippet, based on work by sarg ³:

(transient-define-suffix magit-push-current-agit (source target args)
  :if #'magit-get-current-branch
  :description (lambda () (concat (magit-push--upstream-description) " (agit)"))
  (interactive
   (let ((source (or (magit-get-current-branch)
                     (user-error "No branch is checked out"))))
     (list source
           (magit-get-upstream-branch source)
           (magit-push-arguments))))
  (magit-push-refspecs
   (magit-get "branch" source "remote")
   (concat "HEAD"
           ":refs/for/"
           (magit-get-local-upstream-branch source)
           "/"
           source)
   `(,@args
     ,@(if (or (member "--force" args)
               (member "--force-with-lease" args))
           '("-o" "force-push=true")
         '()))))
(transient-insert-suffix 'magit-push "p"
  '("a" magit-push-current-agit))

This allows me to create a local branch from e.g. the upstream javascript-team branch, make some local changes, and open a Pull Request targeting the upstream javascript-team branch with a quick P a from my magit window.

Some missing features include:

honoring upstream PR templates
dynamically choosing which upstream branch to target with a PR
collaborating with others on PRs via AGit

Footnotes:

Migrating to Codeberg

GNU Guix on Codeberg

sarg's magit configuration snippet

mpv in Emacs

2022-04-14T21:44:00Z

I have two humble requirements for mpv:

Watch a video
Stream music in the background

My venerable Lenovo T400 is suprisingly capable at decoding 1080p video, but doing so has an impact on the responsiveness of the system. An easy way to not do unnecessary work is of course to skip decoding video when I am just listening to music in the background:

mpv --no-video <url-or-path-to-video>

During my Emacs craze in moving my workflow over to EXWM, I found out that mpv is well supported in EMMS. As quite some of the music and videos I enjoy can be found on streaming websites, this does add some new conflicting requirements:

Don't do video decoding for music streamed from e.g. youtube.com
Definitely do video decoding for videos streamed from e.g. youtube.com

While EMMS offers emms-player-mpv-parameters, this only works if I choose to go with one of the two use-cases; Changing the parameters only makes a difference before the mpv IPC server is started.

With the help of the fine folks at #mpv on irc.freenode.net, I learned that you can cycle many properties and options at runtime in mpv, one of which is the video setting. This leads us to the following snippet:

(defun jlicht/cycle-mpv-video ()
  (interactive)
  (and (fboundp 'emms-player-mpv-cmd)
       (emms-player-mpv-cmd '(cycle video))))

Quite short and self-explanatory; if mpv is currently running, it toggles video output (and more importantly, the video decoding with all that entails).

There is a drawback to this approach: if mpv is started with --no-video, it seems to prevent the video capability from being loaded in the first place.

Since EXWM is also a tiling window manager, it is annoying to have mpv windows zooming around all over the place when watching several videos in a playlist. Forcing mpv to unconditionally show a window makes this a lot better:

(setq emms-player-mpv-parameters
      '("--force-window" "--quiet" "--really-quiet" "--no-audio-display"))

This window will simply show a black screen if video output is toggled off. This wouldn't be a post about Emacs without tying it all together in surprisingly simple ways:

(defun play-or-queue-url (url &optional _)
  (if (and (boundp 'emms-player-playing-p) emms-player-playing-p)
      (emms-add-url url)
    (emms-play-url url)))

(setq browse-url-handler
      '(("https:\\/\\/www\\.youtu\\.*be." . play-or-queue-url)))

There you have it: all my requirements met, even the conflicting ones. As an added bonus, youtube links in emacs will now be transparently added to a playlist in emms, such as the ones in Elfeed RSS feeds.

Applying patch series with notmuch

2022-01-07T13:18:00Z

It might be the case that you really like the patch-based workflow, or perhaps you simply want to collaborate on a project where maintainers insist on it. Either way, it makes sense to set up a workflow that works for you.

Dealing with patches is never fun, but it can be easy! I use notmuch mail and its Emacs interface notmuch-emacs to read most of my email, and the vast majority of projects I interact with use git for version control.

(defun apply-open-guix-patches ()
  "Apply all opened patches to my guix source checkout."
  (interactive)
  (notmuch-show-pipe-message t "git -C ~/src/guix am --3way --signoff"))

You will most likely want to customize the command passed to notmuch-show-pipe-message. You could parse both the mailing list header and other parts of the email to dynamically build the command string: notmuch-show-get-subject could be used to select a specific branch and/or worktree to apply your patches to. An integration with project.el or projectile would allow easy selection of which 'project' to apply your patches to.

A patch-based workflow via email might feel antiquated in $CURRENT_YEAR, yet being able to understand, adapt and compose the smaller building blocks tools you depend on is a positive quality that extends to Emacs, git and email in general.

Android development with Guix System in 2021

2021-07-15T15:30:00Z

The majority of work shared in this post is based on work done by Julien Lepiller and shared on their blog. Go read that first if you want to understand what is happening here. Simply follow the instructions under TLDR if understanding is optional, and you just want to hit the ground running.

TLDR

See manifest.scm for the manifest, and container.sh for the container script to launch Android Studio in a container using Guix's environment subcommand.

bash container.sh

Be aware that the container that Android Studio will run in is poked full of holes to support kvm-powered emulation and communication with usb-connected (Android) devices.

Changes compared to Julien's approach

The most straightforward changes I made related to adding dependencies to the container manifest that are now required Android Studio dependencies.

I also made a guix package out of Android Studio itself. The licensing situation is a bit of a mess, and weirdly enough there is only one dependency that seems to be non-free software.

I also opened up some of the restraints on the container in which Android Studio will be running; most of this has to do with getting it to interact with Android devices connected over USB.

Remaining challenges

The current guix package definition for Android Studio is based on the copy-build-system , meaning that things are mostly just copied over.

Android Studio is one of those pieces of software that also helpfully ~~phones home~~ checks in at Google for updates; even worse, since the store is mounted read-only, these updates can not even be installed. It would be an improvement if we can disable or patch out this functionality entirely¹

Starting a guix container by first building a profile, and only then entering a container is a bit of a hassle. I might still look into applying the same trick used to containerize Steam so the "Container Shuffle" can be hidden in day-to-day usage.

If you want to interact with USB-connected Android devices, make sure these devices are already connected when starting Android Studio: If you (re)connect a device while Studio is already running, DDMS will start freaking out and the only thing you can then still do is restart Studio.

Finally, Android Studio is (and will always be) a Google project; this practically also means that you will most likely be forced to read through heaps of EULAs, licenses and all that to even get started with the Android-equivalent of "Hello World". The fabled Someone should really look into getting it all to work using the actual Free Software rebuilds of the Android SDKs. Even better if they write a Guix package definitions for it as well.

Footnotes:

The ideal here would be to create a Guix Updater for making easy updates to the Android Studio Guix package expression.

Guix, docker and Skopeo

2021-07-10T21:52:00Z

Docker is ubiquitous; regardless of its merits. Since my commit to containers/image got upstreamed, you can use Guix in combination with Skopeo to create and share Docker images.

guix install skopeo
skopeo copy --insecure-policy \
       docker-archive:/$(guix pack -f docker hello --entry-point=bin/hello) \
       <some-docker-url-to-push-to>

That --insecure-policy flag might seem worrying, but can be left out by providing your own policy file via the --policy argument. On distributions that are not Guix System, it can probably be left out entirely, as Skopeo comes with a policy installed to /etc/containers/policy.json.

If the previous command complains abouts not being authorized to push to your particular Docker URL, you might still need to set up your Docker registry credentials. Have a look at the skopeo-login command:

skopeo login <some-docker-registry-url>