emacs: add an option to let daemon start after graphical-session.target

[jian-lin]

Description

It's useful if you want emacs daemon to get some environment variables, e.g. ibus related variables when using Gnome.

Checklist

• [X] Change is backwards compatible.

• [X] Code formatted with ./format.

• [ ] Code tested through nix-shell --pure tests -A run.all.

• [X] Test cases updated/added. See example.

• [X] 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.

  • [ ] Added myself and the module files to .github/CODEOWNERS.

[jian-lin]

Ready to merge :)

[Dietr1ch]

I kinda wanted to propose the same thing, but I'm unsure on what's the best way to fix emacs's graphical sessions when using the daemon.

Waiting for default.target makes it start too early, but waiting for graphical-session.target may have unintended consequences,

• What happens if your graphical session gets broken?
  • It seems that it's better to just wait for default.target, and somehow fix things once the graphical session comes up (no clue on whether this is feasible).
• What happens if you just ssh into your machine.
  • Will the daemon start?
  • If not, then doing systemctl --user start emacs might also not work.

Anyway, I do think that I just want to wait for the graphical-session.target by now, things don't break often, and if emacs is not running when I ssh it's fine, I can either use emacs remotely with TRAMP or just start emacs in the foreground if I really need emacs to be running locally.

[jian-lin]

Thanks for your review.

What happens if your graphical session gets broken?

Well, I think you should fix your graphical session then. A broken graphical session is not a common case in my opinion. Even in this case, you can use a non-daemon emacs to fix it.

What happens if you just ssh into your machine.

Will the daemon start?

It will not start if you enable this new option.

If not, then doing systemctl --user start emacs might also not work.

In my test, systemctl --user start emacs can start an emacs daemon.

Here is my test steps:

1. boot my laptop to GDM, but not log in
2. ssh into my laptop
3. systemctl --user status emacs shows it isn't started
4. systemctl --user start emacs will start the daemon

I guess emacs daemon can be manually started because graphical-session.target is not in this transaction, so the After doesn't apply. I am not sure though.

It seems that it's better to just wait for default.target, and somehow fix things once the graphical session comes up (no clue on whether this is feasible).

I prefer to let systemd handle the starting order. Updating environment variables for a running emacs daemon is not easy.

[rycee]

I'm not sure this is needed in the module since it should be relatively simple to override with whichever target you want. Something like

systemd.user.services.emacs = {
  Unit.After = [ "graphical-session.target" ];
  Install.WantedBy = lib.mkForce [ "graphical-session.target" ];
};

perhaps.

[jian-lin]

I'm not sure this is needed in the module since it should be relatively simple to override with whichever target you want

A lot of module options can be relatively simple to override thanks to flexibility of the module system, e.g. https://github.com/nix-community/home-manager/pull/2941.

IMHO, starting emacs daemon after graphical session target like any other graphical programs is a common use case, e.g. @Dietr1ch also needs this, and is suitable to be contained in this module.

[Dietr1ch]

I'd appreciate having the option around. It'd be easier to discover, and it could be set up in a way that auto-detects when you are running a graphical server, which would give a great experience to users IMO.

Without this, users would need to start wondering why things do not work, and hopefully run into this or a similar issue to understand that they'll need to tweak the systemd unit to wait for their graphical environment. That's not a great experience, even though users where free to easily override their configs in the right way from the start.

[jian-lin]

(My reply through email seems to be lost by github.)

it could be set up in a way that auto-detects when you are running a graphical server, which would give a great experience to users IMO.

That would be great but I have no idea how we implement this.

If it's on NixOS and home-manager is used as a NixOS module, we can get the system config from nixosConfig. But what NixOS option should we check? Also, there are cases where home-manager is used as a standalone tool and even on a foreign system.

[stale[bot]]

Thank you for your contribution! I marked this pull request as stale due to inactivity. Please read the relevant sections below before commenting.

If you are the original author of the PR

• GitHub sometimes doesn't notify people who commented / reviewed a PR previously when you (force) push commits. If you have addressed the reviews you can officially ask for a review from those who commented to you or anyone else.
• If it is unfinished but you plan to finish it, please mark it as a draft.
• If you don't expect to work on it any time soon, please consider closing it with a short comment encouraging someone else to pick up your work.
• To get things rolling again, rebase the PR against the target branch and address valid comments.

If you are not the original author of the PR

• If you want to pick up the work on this PR, please create a new PR and indicate that it supercedes and closes this PR.

[jian-lin]

it could be set up in a way that auto-detects when you are running a graphical server, which would give a great experience to users IMO.

That would be great but I have no idea how we implement this.

If it's on NixOS and home-manager is used as a nixos module, we can get the system config from nixosConfig. But what nixos option should we check? Also, there are cases where home-manager is used as a standalone tool and even on a foreign system.

[futile]

This would be extremely useful to have, as currently the emacs daemon is broken for everyone that uses GUI emacs. Which should be quite some people.

Don't really care whether it's this PR, or a simple option that performs the override mentioned by @rycee in https://github.com/nix-community/home-manager/pull/3010#issuecomment-1166241254, but it should be more easily discoverable than having to find this PR/issue #3443.

[DamienCassou]

This would be extremely useful to have, as currently the emacs daemon is broken for everyone that uses GUI emacs.

I have been using this module with GUI Emacs for years without any trouble. I'm not quite sure what kind of trouble people are having. The PR description mentions Gnome which I'm not using though.

I'm fine merging the PR or making graphical-session the default target if that helps people.

[SohamG]

Just finally fixed my ever-broken emacs-daemon/client setup. This was the sole reason I couldnt just use the emacs client setup from home-manager out of the box. Would love to see this merged.

[DamienCassou]

It would be nice to merge this PR.

[SohamG]

Thanks for the quick action everyone!