Re: Adding with-editor to Emacs?

[Jonas Bernoulli <jonas@bernoul.li>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jonas Bernoulli <jonas@bernoul.li>
>> Cc: rms@gnu.org
>> Date: Fri, 01 Sep 2023 16:38:02 +0200
>> 
>> I think the next step is to ask Eli and others, how they would want to
>> integrate the library / the functionality it provides.
>
> I'm probably missing something because if all we want is to allow
> child processes to use the current Emacs session as their editor, we
> just need to inject some environment variables into
> process-environment when running those child processes, and start the
> server.

That's the core of what with-editor does.  Additionally

- It tries hard to find the correct emacsclient to use.

- It implements a "sleeping editor".  This is a shell script, which
  outputs a request on stdout and then waits to be told to return.
  With-editor use a process filter too look for that output and when
  it sees it, it responds in a similar fashion to server.el.  This
  is useful because makes it possible to do this over Tramp.  (I
  believe this could also be done using regular emacsclient+server.el,
  but that is difficult to setup and a security risk if not done
  correctly.

- It provides some convenience functionality to use this from various
  shells running inside Emacs.

> Emacs knows very well where to find its corresponding emacsclient.

I wasn't aware of that.  How can I make use of that knowledge?  I.e.,
is there a function that answers the question "what is the path of the
emacsclient that was installed with this version of emacs"?

> Why is there a need for a separate library?

I agree that there theoretically isn't a need for this library, but it
turned out that just setting EDITOR=emacsclient in the environment of
the sub process also doesn't cut it, because for many users (who never
use emacsclient directly), would have to add some configuration to make
it work.  The core and original functionality provided by with-editor,
is making the configuration unnecessary by using heuristics.

Maybe I miss something, but I concluded that emacs does *not* know
its corresponding emacsclient.  Once I know how to make use of that
knowledge, I can simplify with-editor quite a bit, with will benefit
the packages that already use it.  And if that really is fail-safe,
then Emacs doesn't have much to gain from integrating with-editor.

>> As far as adding `server-window-alist' goes, that would certainly be
>> a win.
>
> If we want to extend server-window in some ways, that could be a
> separate change.  It sounds like its utility is not necessarily
> specific to with-editor or to its main feature of allowing
> sub-processes use the parent Emacs as their editor.

Agreed and that is something I was planning to suggest eventually,
while I had no plan to suggest merging all of with-editor.el.

> (I couldn't find the beginning of this discussion, so maybe I missed
> some of the relevant context, in which case I apologize.)

The text I quoted, was the very beginning of this discussion.