GNU bug report logs -
#71971
31.0.50; Add user option server-window-alist
Previous Next
Full log
Message #23 received at 71971 <at> debbugs.gnu.org (full text, mbox):
> From: Jonas Bernoulli <jonas <at> bernoul.li>
> Cc: michael.albinus <at> gmx.de, 71971 <at> debbugs.gnu.org
> Date: Mon, 08 Jul 2024 19:41:16 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Jonas Bernoulli <jonas <at> bernoul.li>
> >> Cc: 71971 <at> 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.
This bug report was last modified 330 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.