bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Boruch Baum
Subject: bug#33219: crontab -e doesn't connect to existing emacs daemon
Date: Tue, 27 Nov 2018 15:46:26 -0500
User-agent: NeoMutt/20180716

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]