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

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

[Boruch Baum]

When running 'crontab -e' with $EDITOR set to

  emacsclient -nw -c --alternate-editor=""

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

which in this case the emacsclient binary isn't finding or looking for.

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.

A work-around has been to define:

  export EDITOR="$HOME/.local/bin/emacsclient_wrapper"
  alias emacs="emacsclient_wrapper "

  #!/bin/sh
  # emacsclient_wrapper
  SOCKET_FILE="$(lsof -c emacs -u $USER | grep -m1 -o "[^[:blank:]]\+server")"
  [ -z "$SOCKET_FILE" ] \
  && emacsclient -nw -c --alternate-editor="" $@ \
  || emacsclient -nw -c --alternate-editor="" -s "$SOCKET_FILE" $@


In GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2018-08-26, modified by Debian built on x86-csail-01
System Description:	Devuan GNU/Linux 2.0.0 (ascii)

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/25.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.2/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --build x86_64-linux-gnu
 --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/25.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.2/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-x=yes --with-x-toolkit=gtk3
 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs-7bZ65w/emacs-25.2+1=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wall'
 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

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

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

[Glenn Morris]

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.,,

> 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.

> 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.

> 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

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

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

[Glenn Morris]

Boruch Baum wrote:

>> > 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.

I'm saying that you need to investigate why crontab and mutt behave
differently.

For example, perhaps "crontab -e" does not pass TMPDIR to the spawned editor:
https://bugs.debian.org/19237

I verified by doing:
M-: (getenv "TMPDIR")
in the Emacs spawned by crontab that this is indeed the case.

So yes, I think it is a crontab issue.

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

[Boruch Baum]

Recent correspondence for a consequent GNU emacs bug report:

----- Forwarded message from Glenn Morris <rgm@gnu.org> -----

Date: Tue, 27 Nov 2018 00:56:29 -0500
From: Glenn Morris <rgm@gnu.org>
To: Boruch Baum <boruch_baum@gmx.com>
Cc: 33219@debbugs.gnu.org
Subject: Re: bug#33219: 25.2; crontab -e doesn't connect to existing emacs daemon
User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)

>> Boruch Baum wrote (10/31/2018):
>> > 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.

I'm saying that you need to investigate why crontab and mutt behave
differently.

For example, perhaps "crontab -e" does not pass TMPDIR to the spawned editor:
https://bugs.debian.org/19237

I verified by doing:
M-: (getenv "TMPDIR")
in the Emacs spawned by crontab that this is indeed the case.

So yes, I think it is a crontab issue.

----- End forwarded message -----

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

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

[Boruch Baum]

Thanks for pointing out the bug; I've forwarded your mail to that bug thread.


On 2018-11-27 00:56, Glenn Morris wrote:
> Boruch Baum wrote:
>
> >> > 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.
>
> I'm saying that you need to investigate why crontab and mutt behave
> differently.
>
> For example, perhaps "crontab -e" does not pass TMPDIR to the spawned editor:
> https://bugs.debian.org/19237
>
> I verified by doing:
> M-: (getenv "TMPDIR")
> in the Emacs spawned by crontab that this is indeed the case.
>
> So yes, I think it is a crontab issue.

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

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

[Glenn Morris]

Boruch Baum wrote:

> Thanks for pointing out the bug; I've forwarded your mail to that bug thread.

I look forward to the spam from Debian's unobfuscated posting of emails. :(

I will close the Emacs report since it is not an Emacs issue.
As I said earlier EMACS_SOCKET_NAME will exists in future versions,
though I did not check if it is just TMPDIR that crontab does not pass
on.