Re: emacsclient startup messages

[Pedro Andres Aranda Gutierrez]

I remember the controversy with emacs as daemon, emacsclients and friends...

hmmm... from a user's perspective I really don't know what I gain by having emacs running as a daemon if I boot up my laptop to say watch a film or listen to a recording from my satellite PVR just for the fun of it.

Maybe this sounds like a very old user or a very old and very bad habit (mea maxima culpa) but when I want to edit, I write emacs or emacslient on my CLI or click on the emacs icon or drag-and-drop a file on the emacs icon and then emacs stays alive as long as I want it to stay alive. Because, yes, I do watch films and that is somehow not very compatible with writing (code or whatever). Or am I too monotask? ;-)

Best, /PA

On Fri, 5 Nov 2021 at 18:52, Ulrich Mueller <ulm@gentoo.org> wrote:

>>>>> On Fri, 05 Nov 2021, Jim Porter wrote:

> On 11/5/2021 2:40 AM, Ulrich Mueller wrote:
>> $ emacsclient -t --alternate-editor=
>> emacsclient: can't find socket; have you started the server?
>> emacsclient: To start the server in Emacs, type "M-x server-start".
>> Another Emacs daemon is already running at process id 6084
>> Error: server did not start correctly
>> Error: Could not start the Emacs daemon
>> $

> Why are you (or the Gentoo package) running with `--alternate-editor='
> if a daemon was already started?

Because the user may not be sure if a daemon is running, and may want to
start it just in case? Which fails with the patch applied.

Note that the Gentoo package only starts the daemon, calling emacsclient
is up to the user. I'm not keen to receive bug reports because users'
workflows are being broken. (In fact, broken again, as we already had a
round of that with Emacs 27).

> [...]

> As for my personal opinion on this, I think it would be best to revert
> bug#33847 (which supports the Gentoo use-case). If necessary, we could
> provide a way to explicitly opt into the (insecure) bug#33847
> behavior, e.g. by adding a --fall-back-to-tmpdir-sockets flag. I'm
> also ok with my compromise patch, even though it's not perfect.

Not helpful. :(

The main problem with XDG_RUNTIME_DIR ist that it doesn't persist
between login sessions:

| The lifetime of the directory MUST be bound to the user being logged
| in. It MUST be created when the user first logs in and if the user
| fully logs out the directory MUST be removed. [...] Files in the
| directory MUST not survive reboot or a full logout/login cycle.
|
| https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables

In contrast to that, an Emacs running as a daemon can survive logout,
and the user may want to reconnect to it later. This is impossible if
the socket is located in XDG_RUNTIME_DIR, which is scrapped upon logout.

In bug #33847 I had suggested to create the socket in ${HOME}/emacs.d/
instead. Unfortunately this was shot down, with the arguments summarised
in <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33847#100>:

| This would be worse for several reasons: you'd need to disambiguate
| via hostname, you'd need to guarantee hostnames are unique, you'd have
| problems when NFS is flaky or hanging in your home directory, and
| you'd need to deal with socket files that survive OS crashes.

I still don't think that any of these arguments is substantive:

- Unix sockets use the file system just as a namespace, which is unique
  on any given host. The socket itself is local; there is no sharing
  across hosts. Therefore I believe that creating a single socket would
  be enough.

- Flaky NFS shouldn't be a problem, because once the communication is
  established, the filesystem is no longer involved in it. (Of course,
  there may be NFS problems at the time of startup, but then again,
  Emacs cannot read the user's local config either.)

- A stale socket will just use a single inode, and can be reused the
  next time the server is started.

--

Fragen sind nicht da um beantwortet zu werden,

Fragen sind da um gestellt zu werden

Georg Kreisler