bug#71971: 31.0.50; Add user option server-window-alist

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: michael.albinus@gmx.de, 71971@debbugs.gnu.org
> Date: Tue, 09 Jul 2024 21:05:03 +0200
> 
> The fault line isn't between "creating a Git commit" and "everything
> else that uses $EDITOR".
> 
> If I type "git commit" in a terminal, then I want a new frame to popup
> instead of the frame being reused in which I am writing this email.
> 
> If I have staged changes to Emacs in the Magit status buffer for that
> repository and then invoke Magit's command for creating a commit, then
> I do want that frame to be used to write the commit message.
> 
> Only being able to define the behavior globally is exactly what is not
> desirable and taking advantage of the fact that Git allows overriding
> $EDITOR for Git by using $GIT_EDITOR instead, does not solve that
> problem.

One way of solving this is to set $EDITOR outside Emacs, and set
$GIT_EDITOR in process-environment inside Emacs.

> > I'm quite sure you can have that already by using a suitable
> > display-buffer-alist.  All you want is to force
> > switch-to-buffer-other-frame always create a new frame.
> 
> I made that suggestion in response to you writing:
> 
> > It is not even possible to express the "give me a new frame"
> > preference, because the only frame you can mention in the value is an
> > existing frame, and I very much doubt that "normal" users will know
> > how to express even a specific frame there, with the sole exception of
> > the selected one.
> 
> I tough you were saying "there is no way to trivially say 'give me a new
> frame' (so users have to use a mechanism that is to complex for many of
> them)" and responded by saying "we could make it trivial by making
> switch-to-buffer-new-frame available".

What I meant that it's impossible using the server-window like
options.

> >> > And what will
> >> > they use for the REGEXP part? are they supposed to know by heart the
> >> > names of temporary files Git and other VCSes use for editing commit
> >> > messages?
> >> 
> >> Well no, Magit takes care of that, and so could VC.
> >
> > Takes care how? what do you use for REGEXP?
> 
> It adds an entry to with-editor-server-window-alist (which due to an
> advice takes precedence over window-alist), using this regexp:
> 
> "/\\(\
> \\(\\(COMMIT\\|NOTES\\|PULLREQ\\|MERGEREQ\\|TAG\\)_EDIT\\|MERGE_\\|\\)MSG\
> \\|\\(BRANCH\\|EDIT\\)_DESCRIPTION\\)\\'"

That's exactly what I thought: to do something like that the user
needs to know the possible names of files created by Git (and other
VCSes) for editing log messages.  Many/most people don't know that,
and so will have trouble customizing such options.  IOW, the REGEXP
part makes this option work on a very low level, and thus less
friendly than it could be.

> >> > One possibility would be to add a new protocol command telling
> >> > server.el how to create/reuse frames, and then tell users to set
> >> > $EDITOR and similar variables to invoke that command via the
> >> > emacsclient command-line arguments.  Other ideas are welcome.
> >> 
> >> I'm not sure what you mean by "protocol".  More arguments?
> >
> > No, the protocol between emacsclient and the server.  So that the
> > client could tell the server how to create/reuse frames in a more
> > flexible manner than what we have now.
> 
> I still don't understand what kind of suggestion you are looking for.

How does server.el know whether to create a new client frame or reuse
the current one, and what kind of frame to create?  Answer:
emacsclient tells it, via the appropriate commands that are part of
the emacs server to emacsclient protocol.  The protocol is documented
in the doc string of server-process-filter.  In particular, the
command -current-frame tells the server not to create new frames; -tty
tells it to create a TTY frame; etc.

> > I meant to use environment variables only if the preference to reuse
> > an existing frame when editing commit log messages for Git is a
> > globally fixed preference for the user.  In any other case,
> > environment variables are not a good means, because they have global
> > effect and are by default inherited by child processes.
> 
> Environment variables do _not_ have global effect per se, i.e., unless
> they are set in the global environment.  Magit essentially calls
> 
>   EDITOR="emacsclient [...]" git commit
> 
> That $EDITOR only affects this one "git" invocation and its children.

That's unportable.  On some systems, environment variables will be
inherited by subprocesses of "git commit".

> If the "protocol" could be extended to pass along other preferences,
> that would be useful (and it was my impression that you requested input
> on how that could be done).  Environment variables could be used, as
> could new arguments
> 
>   SERVER_WINDOW=switch-to-buffer-new-frame EDITOR=emacsclient git commit
> 
> or
> 
>   EDITOR="emacsclient --server-window=switch-to-buffer-new-frame" git commit
> 
> Of course if the only choices we care about are "--create-frame" and
> "--reuse-frame", well, these already exist.
> 
> [[[Side-note: And these are actually the only choices *I* have come
> to care about.  So I am not particularly interested, in making other
> choices available anymore.  This limited interest likely affect the
> quality of my suggestions.]]]
> 
> But you said
> 
> > we
> > need a more user-friendly feature, using which users will be able to
> > easily control the server's frame-creation behavior depending on some
> > predictably-deterministic attribute of the connection or the client.
> 
> I.e., "having the choice between -c/-r/-t is not enough".  In this
> context my suggestion to support --server-window=SENSIBLE-FUNCTION
> continues to make sense to me.
> 
> I guess it's this part that is too vague for me:
> 
> > ... depending on some predictably-deterministic attribute ...
> 
> because, to me, command-line arguments, environment variables and
> server-window-alist all satisfy this requirement, i.e., they are
> channels that could be used to "communicate" that "attribute".

Not when commands (such as emacsclient) are invoked from Emacs by Lisp
programs.  In that case, it is the Lisp program that must decide which
command-line switches of emacsclient to use, and my bothr is how to
let users specify that in a way that is both powerful and flexible,
and user-friendly.  Using regexps that match files or buffers is not
user-friendly enough to my palate in this case.