clipmenu: Add environmentVariables option

[evenbrenden]

Description

Add environmentVariables option for setting e.g. CM_MAX_CLIPS for clipmenud.

From what I gather, variables set in home.sessionVariables are not picked up by the service, so the lancher option does not currently work. With this change, CM_LAUNCHER can be set with environmentVariables, so I suggest deprecating the launcher option.

Checklist

• Change is backwards compatible.

• Code formatted with nix fmt or
  nix-shell -p treefmt nixfmt deadnix keep-sorted --run treefmt.

• Code tested through nix run .#tests -- test-all or
  nix-shell --pure tests -A run.all.

• Test cases updated/added. See example.

• Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  See CONTRIBUTING for more information and recent commit messages for examples.

• If this PR adds a new module

  • Added myself as module maintainer. See example.
  • Generate a news entry. See News
  • Basic tests added. See Tests

• If this PR adds an exciting new feature or contains a breaking change.

  • Generate a news entry. See News

[teto]

is it possible to pass the setting to the executable instead ? e.g. ExecStart = "${cfg.package}/bin/clipmenud ${cfg.extraArgs}";.
You can modify systemd.user.services.clipmenu.Service.Environment yourself without modifying the module too.

[evenbrenden]

is it possible to pass the setting to the executable instead ? e.g. ExecStart = "${cfg.package}/bin/clipmenud ${cfg.extraArgs}";.

No, clipmenud is only configured using enviroment variables, it seems.

You can modify systemd.user.services.clipmenu.Service.Environment yourself without modifying the module too.

Nice, I didn't think of that. I don't mind closing this PR if you think that's the better way. Note my comment about the launcher option, though.

[teto]

as you prefer. In its current state the PR doesn't add much abstraction, it just does somehting already possible without modification in a different way, which adds complexity.
if it's something new, it could be a maxClips number ? we could wait for maintainer feedback and see if others find it useful. Note also that you can extend existing home-manager modules in your own config see https://github.com/teto/home/tree/main/hm/modules for example.

[evenbrenden]

if it's something new, it could be a maxClips number ?

Sure, we could consider tightening the interface like that. These are the available options:

- $CM_DEBUG: turn on debugging output (default: 0)
- $CM_DIR: specify the base directory to store the cache dir in (default: $XDG_RUNTIME_DIR, $TMPDIR, or /tmp)
- $CM_MAX_CLIPS: soft maximum number of clips to store, 0 for inf. At $CM_MAX_CLIPS + 10, the number of clips is reduced to $CM_MAX_CLIPS (default: 1000)
- $CM_ONESHOT: run once immediately, do not loop (default: 0)
- $CM_OWN_CLIPBOARD: take ownership of the clipboard. Note: this may cause missed copies if some other application also handles the clipboard directly (default: 0)
- $CM_SELECTIONS: space separated list of the selections to manage (default: "clipboard primary")
- $CM_IGNORE_WINDOW: disable recording the clipboard in windows where the windowname matches the given regex (e.g. a password manager), do not ignore any windows if unset or empty (default: unset)

also that you can extend existing home-manager modules in your own config see https://github.com/teto/home/tree/main/hm/modules for example.

I figured this might be a welcome upstream change. Overriding "internal" attributes decouples them from the configuration, and is prone to silently failing (e.g. if the name of the service is changed).