Re: with-editor seems like a bug fix

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Manuel Giraud <manuel@ledu-giraud.fr>,  rms@gnu.org,
>   emacs-devel@gnu.org, Jonas Bernoulli <jonas@bernoul.li>
> Date: Sat, 29 Jun 2024 13:06:54 +0200
> 
> >> 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.

My conclusion from discussing the local case was that problems with
finding the right version of emacsclient, such as they are, are
limited to broken Emacs installations.  There was also a possibility
that these problems exist in valid installations, but no one was able
to describe such situations.  Until someone does, I don't see why we
should consider what we have buggy.

What I was asking was limited to the remote case.

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

What you say here seems to imply that the remote case cannot be solved
in principle?

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

I don't see how we can discuss a package which solves problems we
don't understand.  Until and unless someone describes the problems
which with-editor solves in enough detail for us to understand what
goes wrong and where, I don't think we can discuss the addition of the
package to core.

Thanks.