From: Michael Albinus <michael.albinus@gmx.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Manuel Giraud <manuel@ledu-giraud.fr>,
rms@gnu.org, emacs-devel@gnu.org,
Jonas Bernoulli <jonas@bernoul.li>
Subject: Re: with-editor seems like a bug fix
Date: Sat, 29 Jun 2024 13:06:54 +0200 [thread overview]
Message-ID: <87msn4nh2p.fsf@gmx.de> (raw)
In-Reply-To: <8634oy65mo.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 27 Jun 2024 13:29:19 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
Hi Eli,
>> >> What with-editor does seems like a bug fix to me, not like a feature.
>> >> It really ought to be standardly enabled in Emacs whenever the Emacs
>> >> client is.
>> >
>> > If someone can explain what is/are the bug(s) and show a recipe for
>> > reproducing it/them, we will fix it, yes.
>>
>> I said it in september 2023 and I don't know if it's a bug that needs a
>> fix but here is recipe of what 'with-editor' does well and could be
>> useful:
>>
>> - C-x C-f /ssh:remote-server|su::
>> - M-x eshell
>> - vipw --> and here it works, opening an Emacs buffer through
>> emacsclient so I could edit and C-c C-c when done
>>
>> Note that:
>> - EDITOR is set to "emacsclient" on the localhost
>> - Emacs/emacsclient is not installed on remote-server
>>
>> It seems that 'with-editor' does that with the following shell hackery
>> into $EDITOR on the remote server:
>>
>> sh -c 'printf "\nWITH-EDITOR: $$ OPEN $0\037$1\037 IN $(pwd)\n"; sleep
>> 604800 & sleep=$!; trap "kill $sleep; exit 0" USR1; trap "kill $sleep;
>> exit 1" USR2; wait $sleep'
>
> Ouch!
>
>> So maybe that is what we need in Emacs if we want this feature.
>
> I hope not.
>
> Michael, can you please look into this and see what can we do in such
> cases?
As Manual says, we've discussed this last autumn.
In the local case, with-editor tries to set a proper environment for
calling emacsclient from child processes started in Emacs. This could
be 'git commit', 'vipw', 'crontab -e', whatever. Mainly it solves two
tasks: searching for a proper emacsclient program (which isn't trivial,
as Jonas did explain), and setting the $EDITOR environment variable when
calling the child process.
In the remote case, when a program is called on another host,
with-editor doesn't use emacsclient at all. Finding a proper emacsclient
remotely is more complicate, and setting the $EDITOR environment
variable needs more logic, because it must use emacsclient's -T
argument. Jonas has said that he doesn't use Tramp himself, so using a
remote emacsclient wasn't an option for him. The emacsclient -T argument
exists since Emacs 26; the with-editor package requires Emacs 25.1, it
wasn't available when the package started to exist.
And there are even more problems using a remote emacsclient program. It
simply coouldn't exist remotely. It simply couldn't be possible to use a
socket from the remote host back to the local host, for example if the
local host is indide a firewall, and the remote host isn't. It simply
couldn't be possible to establish a socket at all from the remote host
to the local host, when the remote host is reachable via a (Tramp)
multi-hop path only, like "/ssh:user1@proxyhost|ssh:user2@targethost:".
TL;DR: I don't believe with-editor is just a bug fix. There are reasons
for the implementation as-it-is. It might profit from using
emacsclient also for the remote case (when possible), but nobody
has taken the stab.
Best regards, Michael.
next prev parent reply other threads:[~2024-06-29 11:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-27 3:07 with-editor seems like a bug fix Richard Stallman
2024-06-27 5:58 ` Eli Zaretskii
2024-06-27 6:14 ` Po Lu
2024-06-27 9:44 ` Manuel Giraud via Emacs development discussions.
2024-06-27 10:29 ` Eli Zaretskii
2024-06-27 10:58 ` Michael Albinus
2024-06-29 11:06 ` Michael Albinus [this message]
2024-06-29 12:38 ` Eli Zaretskii
2024-06-29 12:47 ` Michael Albinus
2024-06-29 12:58 ` Eli Zaretskii
2024-06-29 14:39 ` Michael Albinus
2024-06-29 15:58 ` Eli Zaretskii
2024-06-29 16:08 ` Michael Albinus
2024-07-02 19:43 ` Jonas Bernoulli
2024-07-06 11:15 ` Michael Albinus
2024-06-30 11:51 ` Manuel Giraud via Emacs development discussions.
2024-07-01 1:52 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87msn4nh2p.fsf@gmx.de \
--to=michael.albinus@gmx.de \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=jonas@bernoul.li \
--cc=manuel@ledu-giraud.fr \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).