bug#33219: 25.2; crontab -e doesn't connect to existing emacs daemon

[Boruch Baum]

On 2018-11-01 12:25, Glenn Morris wrote:
> Boruch Baum wrote:
>
> > When running 'crontab -e' with $EDITOR set to
> >
> >   emacsclient -nw -c --alternate-editor=""
>
> I'm never sure whether EDITOR allows program name plus arguments,
> separated by whitespace.,,

Yep. Just quote the variable, and apply backslashes to the internal
quotes.

>
> > emacsclient issues an error that it had failed to locate the emacs
> > daemon socket file, so it spawns a new emacs daemon. On this
> > distribution (Devuan Ascii/Ceres, a derviative of Debian 9 without
> > systemd), the socket file is located at:
> >
> >   /tmp/user/${UID}/emacs${UID}/server
>
> emacsclient looks in TMPDIR/emacs${UID}/server, or /tmp if TMPDIR is unset.
> Is TMPDIR set to /tmp/user/${UID} ?
> Otherwise I would not expect this to work.

That is at least part of the issue of this report. In my case, TMPDIR
_is_ set to /tmp/user/$UID, yet the emacsclient still reports that it
was unable to find the socket file.

>
> > However, in other uses of emacsclient via $EDITOR (eg. mutt, newbeuter,
> > w3m) the client does find the socket file and does connect to the
> > existing daemon.
>
> Then I'm confused as to how this is supposed to be an Emacs issue.

Well, it is emacsclient that is reporting that it can not operate as
expected when called by a core *nix utility. Think of the alternative:
if I file a report against 'crontab', those guys will correctly tell me
that they just use the $EDITOR value, that emacsclient _is_ being
launched, and the error happens within emacsclient.

> > A work-around has been to define:
> >
> >   export EDITOR="$HOME/.local/bin/emacsclient_wrapper"
>
> Future emacsclient will respect the EMACS_SOCKET_NAME environment variable;
> ref http://lists.gnu.org/r/emacs-diffs/2018-10/msg00191.html

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0