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

[Eli Zaretskii <eliz@gnu.org>]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: michael.albinus@gmx.de, 71971@debbugs.gnu.org
> Date: Mon, 08 Jul 2024 19:41:16 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Jonas Bernoulli <jonas@bernoul.li>
> >> Cc: 71971@debbugs.gnu.org
> >> Date: Sat, 06 Jul 2024 16:16:21 +0200
> >> 
> >> So in summary, it is possible for the same person to want the behavior
> >> to be different in different situations.  The fact that "committing from
> >> Emacs using Magit" involves the use of emacsclient, just like "quickly
> >> edit a file from the terminal" does, is an implementation detail, and
> >> should not make it necessary for the user to decide which use-case
> >> should be optimized to their liking, at the cost of undesirable behavior
> >> in the other case.
> >
> > That sounds to me like the value of $EDITOR should be "emacsclient -c"
> > whereas the value of $GIT_EDITOR should be just "emacsclient"?
> 
> Who would set those variables to those values?

The user, of course.  But see below.

> Where?

In the system's or shell's init files, depending on the system and the
user's needs.

> I am beginning to think that at least for Magit's needs the new
> --create-frame is sufficient.  It could just call
> 
>   EDITOR="emacsclient -c" git commit
> 
> Unfortunately that's a fairly new argument

"New"? AFAICT, it exists since Emacs 23.1, i.e. for the last 15 years.

> so with-editor will have to keep providing an alternative.  But when
> it comes to the question of whether server-window-alist should be
> added to future Emacs releases, that isn't a concern.
> 
> I understand your hesitancy to add such a variable.  I am not sure it
> is necessary anymore either.

Agreed.

> That being said, maybe adding switch-to-buffer-new-frame wouldn't be
> such a bad idea.

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.

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

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

> You mention environment variables.  If I remember correctly, I did
> experiment with that, but ran into the problem that while it was
> possible to pass along additional environment variables when using
> "emacsclient --tty", the same was not possible when using "emacsclient
> --create-frame".

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.