feat: work on distributions other than Arch

The README asked for "Arch or an Arch derivative" and the code had two
reasons for it. Neither of them was the mechanism, which is why this is
mostly a matter of not assuming.

The first was the flag file. Arch wraps Electron and Chromium in launchers
that read $XDG_CONFIG_HOME/<name>-flags.conf, and that route is the good
one - it survives upgrades and applies to a launch from a terminal. Debian,
Ubuntu, Fedora and openSUSE keep the equivalent under /etc, where it is the
system's file and not the user's, so there is nothing to write and those
applications have to go through their desktop entry instead. That already
worked, because a launcher is read rather than assumed - but only if the
launcher was recognised as Chromium at all, and it was not:

    APPNAME=chromium
    LIBDIR=/usr/lib/chromium
    exec -a "$APPNAME" "$LIBDIR/$APPNAME" $CHROMIUM_FLAGS "$@"

is the shape every one of those wrappers has, and following it needs the
assignments above resolved and -a understood as renaming the process rather
than naming the program. Both are done now, and the wrappers that still
cannot be followed are caught by CHROMIUM_FLAGS and CHROME_WRAPPER, which
nothing but a Chromium launcher sets. Two applications on the machine this
was written on turn out to have been missed for the same reason: Helium,
whose wrapper is followed to a payload full of markers, and ONLYOFFICE,
which ships libcef.so.

Resolving more wrappers made an old inference dangerous. Any launcher that
could be followed also had "<target>-flags.conf" invented for it, on the
theory that a wrapper builds that name from a variable at runtime. For an
application that simply execs its own binary that file is read by nobody:
the flag would have gone to ~/.config/DesktopEditors-flags.conf and the
desktop entry that would have worked was skipped. The name is now derived
only once the target has shown it reads a flag file at all.

The second reason was snaps. /snap/bin/<name> is a symlink to snapd, so
following it lands on /usr/bin/snap and says nothing; the payload is in the
mounted revision, and that tree takes the same marker check as anything
else. They get a settings switch of their own next to Flatpak, and the
launcher entry as their only way in.

Packaging is now a gate in front of the category rather than a category
beside it. A Chromium installed as a snap or a Flatpak was filed as neither
an application nor a browser, so turning browsers off did not reach it -
which on Ubuntu means the default browser. It is a browser that happens to
be packaged as a snap, and both switches apply.

The rest is the same not-assuming: Steam is found in Debian's
~/.steam/debian-installation and in the snap's private tree, the Flatpak
and snap export directories are scanned even when a session started before
they were installed left them out of XDG_DATA_DIRS, /usr/lib/x86_64-linux-gnu
counts as a shared directory the way /usr/lib does, the watcher covers
snapd's export directory and the NixOS and Guix profiles, LANG is read from
/etc/default/locale as well as /etc/locale.conf, and the systemd user unit
directory is asked of systemd instead of guessed - while still following a
PREFIX that was asked for.

README.md

@@ -10,10 +10,14 @@ underneath are identified by what they ship rather than by their name, and each
 of them is handled.
 
 ```bash
-paru -S middleclick-autoscroll
+paru -S middleclick-autoscroll     # Arch and its derivatives
 middleclick-autoscroll enable
 ```
 
+There is no package for anything else yet, so elsewhere it is `make && sudo
+make install` from a checkout and then the same one command. See
+[Building from source](#building-from-source).
+
 That is the whole setup. Nothing else has to be configured, and no file has to
 be edited.
 
@@ -31,9 +35,10 @@ back on:
 Getting that argument into one application is a five-minute job. Getting it into
 all of them, in a way that survives the next package upgrade, is not:
 
-- Some applications read a flag file, some don't.
+- Some applications read a flag file, some don't - and which do depends on the
+  distribution as much as on the application.
 - Some ship their own copy of Electron, some use the system one.
-- Flatpaks see none of the host's configuration.
+- Flatpaks and snaps see none of the host's configuration.
 - An application that starts itself at login uses a different entry than the one
   in the menu, and Discord launched at login used to behave differently from
   Discord launched by hand.
@@ -83,7 +88,7 @@ on — with the space bar:
 ```
 
 **[4] Settings** has the categories — Electron and CEF applications, browsers,
-Flatpaks, autostart entries, Steam, Spotify, whether to watch for new
+Flatpaks, snaps, autostart entries, Steam, Spotify, whether to watch for new
 applications, and a field for extra Chromium arguments if you want any.
 
 There is a configuration file behind all of this. You are never asked to open
@@ -95,8 +100,12 @@ Two routes, picked per application.
 
 | | |
 |---|---|
-| **Flag file** | Arch's Electron and Chromium wrappers read extra arguments from `~/.config/<name>-flags.conf`. This is the good one: it is the supported way to pass arguments, it survives package upgrades untouched, and it applies to a launch from a terminal as much as one from the menu. |
-| **Desktop entry** | For applications that ship their own binary with no wrapper, and for Flatpaks, a copy of the entry with the argument appended goes into `~/.local/share/applications`, where it shadows the system one. |
+| **Flag file** | Where the launcher reads extra arguments from `~/.config/<name>-flags.conf`. This is the good one: it is the supported way to pass arguments, it survives package upgrades untouched, and it applies to a launch from a terminal as much as one from the menu. Arch's Electron and Chromium packages all work this way, and a number of individual vendors' launchers do everywhere else. |
+| **Desktop entry** | For applications that ship their own binary with no wrapper, and for everything inside a Flatpak or a snap, a copy of the entry with the argument appended goes into `~/.local/share/applications`, where it shadows the system one. |
+
+Which of the two an application ends up on is decided by reading its launcher,
+never by knowing which distribution this is. Nothing here has a list of
+distributions in it any more than it has a list of applications.
 
 Entries that already live in `~/.local/share/applications` — AppImages, web app
 shortcuts — are edited in place and the original is kept. So are the entries in
@@ -148,10 +157,15 @@ started once, at the start.
 ## Applications installed later
 
 A systemd user path unit watches every directory a launcher can appear in —
-`/usr/share/applications`, the Flatpak exports, `~/.local/share/applications`,
-`~/.config/autostart` — plus Steam's helper script. Anything new is handled
-within a second of being installed, whether it came from pacman, the AUR,
-Flatpak or an AppImage manager. There is no hook to install per package manager.
+`/usr/share/applications`, the Flatpak exports, snapd's export directory, the
+NixOS and Guix profiles, `~/.local/share/applications`, `~/.config/autostart` —
+plus Steam's helper script. Anything new is handled within a second of being
+installed, whether it came from pacman, apt, dnf, zypper, the AUR, Flatpak,
+snapd or an AppImage manager. There is no hook to install per package manager,
+which is the only reason one program can cover all of them.
+
+Without systemd nothing breaks; new applications are picked up the next time
+`middleclick-autoscroll apply` runs instead of on their own.
 
 ## What it will not guess
 
@@ -191,11 +205,34 @@ Run this before uninstalling the package.
 
 See `man middleclick-autoscroll` for the details.
 
+## Distributions
+
+Any of them. Nothing here is keyed to a distribution name — what differs is
+which of the two routes above an application ends up on, and that is read off
+its launcher.
+
+On Arch and its derivatives most Electron and Chromium packages ship a wrapper
+that reads a flag file, so most applications take that route. On Debian,
+Ubuntu, Fedora and openSUSE the equivalent file lives under `/etc` and belongs
+to the system rather than to you, so there is no flag file to write and those
+applications go through their launcher entry instead. Both work. The flag file
+is only the nicer of the two, because it applies to a launch from a terminal as
+well.
+
+Snaps are handled the way Flatpaks are: what a snap ships lives in its own
+mounted tree, `/snap/bin/<name>` is a shim into snapd and says nothing about
+what is behind it, and the launcher entry is the only way in. Each has a switch
+of its own in the settings.
+
+Steam is found wherever the installation actually is — `~/.local/share/Steam`
+for Valve's own package and Arch's, `~/.steam/debian-installation` for
+Debian's, and inside the private tree for the Flatpak and the snap.
+
 ## Requirements
 
-Arch or an Arch derivative (CachyOS, EndeavourOS, Manjaro), bash, systemd for
-the watcher. Nothing outside your home directory is ever written to, and running
-it as root is refused.
+Bash 4.2 or newer, GNU coreutils, and systemd for the watcher — that is all,
+and it is what a desktop Linux install already has. Nothing outside your home
+directory is ever written to, and running it as root is refused.
 
 ## Building from source
 
@@ -204,6 +241,16 @@ make
 sudo make install
 ```
 
+`make` needs `msgfmt` (gettext) for the translations and `scdoc` for the man
+page; both are optional and skipped with a note when missing. `make install`
+puts the systemd user units where systemd itself says they go, and honours the
+usual `PREFIX` and `DESTDIR`:
+
+```bash
+make PREFIX=/usr/local
+sudo make PREFIX=/usr/local install
+```
+
 `make check` runs `bash -n` and, if installed, `shellcheck` over every script.
 
 ## License