Failure after update of Emacs from 28.2 to 29.1

[yalfg]

I've been using magit (and then with-editor) with a custom installation of Emacs 28.2 (and earlier from 27.1) without problem. After an update of Emacs to 29.1, I have a warning on opening the magit status:

 ■  Warning (with-editor): Cannot determine a suitable Emacsclient

Determining an Emacsclient executable suitable for the
current Emacs instance failed.  For more information
please see https://github.com/magit/magit/wiki/Emacsclient.

Running with-editor-debug gives:

with-editor: /home/user/.emacs.d/elpa/with-editor-3.3.0/with-editor.el
emacs: /usr/local/bin/emacs-fsf (29.1)
system:
  system-type: gnu/linux
  system-configuration: x86_64-pc-linux-gnu
  system-configuration-options: --prefix=/usr/local/stow/emacs-29.1 --program-suffix=-fsf --with-json --with-tree-sitter --with-native-compilation --with-file-notification=yes --with-xwidgets 'CFLAGS=-O2 -march=native'
server:
  server-running-p: t
  server-process: nil
  server-use-tcp: nil
  server-name: server
  server-socket-dir: /run/user/1000/emacs
    server
  server-auth-dir: ~/.emacs.d/server/
    WARNING: not an accessible directory
with-editor-emacsclient-executable:
 value:   nil (nil)
 default: nil (nil)
 funcall: nil (nil)
path:
  $PATH: "/home/user/bin:/home/user/.cargo/bin:/usr/local/sbin:/usr/local/bin:/snap/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/games:/home/user/.local/bin"
  exec-path: (/home/user/bin /home/user/.cargo/bin /usr/local/sbin /usr/local/bin /snap/bin /usr/sbin /usr/bin /usr/games /usr/local/games /home/user/.local/bin /usr/local/stow/emacs-29.1/libexec/emacs/29.1/x86_64-pc-linux-gnu)
  with-editor-emacsclient-path:
    /usr/local/stow/emacs-fsf/bin (t)
      /usr/local/stow/emacs-fsf/bin/emacsclient-fsf (29.1)
    /home/user/bin (t)
      /home/user/bin/myemacsclient (nil)
    /home/user/.cargo/bin (t)
    /usr/local/sbin (t)
    /usr/local/bin (t)
      /usr/local/bin/emacsclient-fsf (29.1)
    /snap/bin (nil)
    /usr/sbin (t)
    /usr/bin (t)
      /usr/bin/emacsclient (28.2)
      /usr/bin/emacsclient.emacs (28.2)
    /usr/games (t)
    /usr/local/games (t)
    /home/user/.local/bin (t)
    /usr/local/stow/emacs-29.1/libexec/emacs/29.1/x86_64-pc-linux-gnu (t)

I'm not using TCP (local to a machine) so the lack of ~/.emacs.d/server/ shouldn't be a problem.

The proper emacsclient-fsf executable is found: this upstream, self compiled Emacs 29.1 is installed under /usr/local/stow/emacs-29.1 and linked under /usr/local/bin using stow. So this looks good.

A specific thing of my setup (maybe?) is that I'm running an Emacs server using systemd, but the issue is from a different Emacs instance. I prefer using an Emacs instance per project, and the systemd server is only there to support automation like hooking Firefox/Thunderbird to TB. Could this be an issue?

When running manually the correctly found emacsclient, it works fine and connect to the systemd background instance (as expected).

Thanks

[yalfg]

I forgot to mention: if I set with-editor-emacsclient-executable to this same emacsclient, it works fine.

[tarsius]

The proper emacsclient-fsf executable is found: this upstream, self compiled Emacs 29.1 is installed under /usr/local/stow/emacs-29.1 and linked under /usr/local/bin using stow. So this looks good.

It is not being found by with-editor-locate-emacsclient-1:

with-editor-emacsclient-executable:
 value:   nil (nil)
 default: nil (nil)
 funcall: nil (nil)

The reason is the unexpected -fsf suffix. Did you yourself chose to add that suffix? Why? It seems you didn't do that before.

I forgot to mention: if I set with-editor-emacsclient-executable to this same emacsclient, it works fine.

If you indeed added the suffix yourself and want to stick to that, then you should probably just continue to set that variable yourself. I have added code to detect emacsclients that aren't actually named emacsclient in the past, but only if someone chose to do something weird and distributes that build to others.

[yalfg]

Thanks for the feedback, I misunderstood the trace. Yes, the suffix is intentional: I'm on Debian and the Debian package is also installed due to some dependencies. I added the suffix to avoid a clash between the Debian version and my self compiled upstream version. But this is nothing new, I've added such prefix with all my previous self compiled versions.

Maybe in the past the Debian emacs client happened to work with the upstream Emacs, and now with 29.1 it's no longer the case?

Anyway, thanks for clarifying and setting the variable is fine by me.

[tarsius]

But this is nothing new, I've added such prefix with all my previous self compiled versions.

Maybe in the past the Debian emacs client happened to work with the upstream Emacs, and now with 29.1 it's no longer the case?

The difference probably is that you installed 28.x using apt and manually, but Debian hasn't packaged 29.1 yet, so that you have only installed manually. Previously even if you used manually installed emacs, with-editor used the (compatible) emacsclient that was installed using apt (because that's the one with the expected name and expected version).

I added the suffix to avoid a clash between the Debian version and my self compiled upstream version.

Wouldn't it make more sense to install in /usr/local or /opt? (I don't know the stow way.)

[yalfg]

Yes you're right, it's likely that with backports the Debian and upstream versions happened to always be aligned so far. So it worked by random luck!

I'm actually installing under /usr/local. stow is just a tool to help add/remove things there. But for some things the local version must take precedence, and here it wouldn't (not to break things depending on the Debian version), and there's in practice a single path order.

It would be possible to use a script (called emacs-fsf maybe ;) to set the path, this way it'd be transparent to my upstream Emacs. But the suffix looked like an official way to deal with this directly as it's an Emacs configure option.

Anyway, not a problem now that I understand what's going on. I reported this following the with-editor documentation but using with-editor-emacsclient-executable in this case is fine, I agree using a suffix is likely rare in practice.

Thanks for the help!

[tarsius]

You are welcome!