Re: with-editor seems like a bug fix

[Michael Albinus <michael.albinus@gmx.de>]

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.