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

[Jonas Bernoulli]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Jonas Bernoulli <jonas@bernoul.li>
>> Date: Sat, 06 Jul 2024 13:06:57 +0200
>> From:  Michael Albinus via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> A new user option `server-window-alist' shall be added to server.el. Every
>> entry shall be of type (REGEXP . SERVER-WINDOW). REGEXP is used to filter
>> for the buffer's file name, and if it matches, SERVER-WINDOW shall be
>> applied. SERVER-WINDOW itself has the same type as the `server-window'
>> user option.
>> 
>> If no regexp matches, the value of user option `server-window' shall be
>> used.
>> 
>> This new user option is the same as the existing
>> `with-editor-server-window-alist' from package with-editor.el. Mid-term,
>> the former shall replace the latter.
>
> Is it possible to describe the typical use cases which this option
> targets?  Given that client frames/windows are not meant for specific
> buffers (IOW, a client frame/window can be used for editing several
> buffers), what kind of workflow will benefit from this option?
>
> (And please don't say "the same cases as those where server-window is
> useful", because I don't understand its usefulness, either.)

It is possible for the same person to want the behavior to be different
in different situations.

I, for example, generally prefer switch-to-buffer-other-frame.  If I
invoke "emacsclient" multiple times, then I don't want the same
frame/window to be reused. I want a new frame for each invocation, so
that I can think of them as "dialogues" that can be handled individually
and not necessarily in order.  Using dedicated frames helps with that.

Other people might feel the same way and use the same value for
server-window -- after all it is one of the suggested values.

Usually I only edit one file via emacsclient at a time.  That file most
often has absolutely nothing to do with whatever else is happening in
the emacs instance it connects to.  Basically I want emacsclient to
behave as much like another emacs instance as possible.  If not for the
startup time, I would actually use a new instance to guarantee a clean
slate.  Using a new frame is both a good enough alternative to full
separation and the absolute minimal amount of separation I in such
cases.

However, when creating a commit from within Emacs using Magit, then the
situation is different.  Many users do not even realize that this
involves the use of $EDITOR=emacsclient.  And indeed it doesn't have to
be implemented that way.  Magit's commit command could instead create
a buffer to write the message itself and once the user indicates that
they are done, it would call "git commit -m (buffer-string)".

Especially if the latter is one's mental modal of what happens when
creating a commit, and one generally doesn't create many frames and
instead relies on buffer switching inside existing frame(s), then it
would be surprising if a new frame were created.  And even I who knows
what is going on and generally rely heavily on short-lived frames, would
not want a new frame to popup in this case.

I common sequence of tasks would be.
1. Edit file.
2. Bring up Magit status buffer.  The status buffer is displayed in the
   window previously displaying the file-visiting buffer.
3. Stage all or some of the changes.
4. Invoke the commit command.

At this point one would expect the commit command to behave the same as
the show-status command.  The current buffer is replaced with the new
"dialog like" buffer.  But if one configured server-window as I have
described above, to handle a completely different situation to one's
liking, then that is not what would happen.

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.