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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 06 Jul 2024 17:47:53 +0300

> From: Jonas Bernoulli <[email-masked]>
> Cc: [email-masked]
> 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"?  IOW,
what you describe involves workflows some of which want a new client
frame and some want to reuse the same frame.

But the server-window variable and the proposed server-window-alist
are about having certain _buffers_ display in certain _windows_.  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.  So, AFAICT, to support the two varieties you described,
users will almost always need to write a function and put it into the
alist elements' SERVER-WINDOW slots, is that right?  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?

My conclusion is that if we want to support the above workflows, 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.
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.