From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jonas Bernoulli via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#71971: 31.0.50; Add user option server-window-alist Date: Tue, 09 Jul 2024 21:05:03 +0200 Message-ID: <87wmlutmhs.fsf@bernoul.li> References: <871q463hke.fsf@gmx.de> <86cynq4vfa.fsf@gnu.org> <87msmuvc5m.fsf@bernoul.li> <86wmly37c6.fsf@gnu.org> <871q43vl1f.fsf@bernoul.li> <86y16bzs0w.fsf@gnu.org> Reply-To: Jonas Bernoulli Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5962"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael.albinus@gmx.de, 71971@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 09 21:06:21 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sRGAO-0001FT-Ad for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Jul 2024 21:06:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sRGA3-0000sr-Jt; Tue, 09 Jul 2024 15:05:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRGA2-0000sj-8k for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2024 15:05:58 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sRGA2-0003xV-0I for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2024 15:05:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sRGA6-0003WS-Ji for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2024 15:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jonas Bernoulli Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Jul 2024 19:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71971 X-GNU-PR-Package: emacs Original-Received: via spool by 71971-submit@debbugs.gnu.org id=B71971.172055191813470 (code B ref 71971); Tue, 09 Jul 2024 19:06:02 +0000 Original-Received: (at 71971) by debbugs.gnu.org; 9 Jul 2024 19:05:18 +0000 Original-Received: from localhost ([127.0.0.1]:54099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRG9N-0003VB-FY for submit@debbugs.gnu.org; Tue, 09 Jul 2024 15:05:18 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:53566) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRG9J-0003V1-Qu for 71971@debbugs.gnu.org; Tue, 09 Jul 2024 15:05:15 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id B6584164CE; Tue, 9 Jul 2024 21:05:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :references:in-reply-to:subject:subject:from:from; s=sel2011a; t=1720551905; bh=D2JWF2donJm+498BimfBcSflyMon3KYcezDBT1XrWzE=; b= jl2kl0Ap1fXDc64lQXzl6rlnw7Sz0kWjZZJyOTZy6xlfjKRuXLCqwXpFZFWuzxBA ky03zw0jYBvR+DwYgmai5ogWe18Fzp+0HAPcWCiIPbtnmqAXRQGiOI97Yn1uMPHP nSKTce8XEKLls1F7yesvsjwyldn2uDmK8OGS5XpJRJQ= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail0.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id sDLEIQiflmzu; Tue, 9 Jul 2024 21:05:05 +0200 (CEST) Original-Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 0789916463; Tue, 9 Jul 2024 21:05:03 +0200 (CEST) In-Reply-To: <86y16bzs0w.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:288649 Archived-At: Eli Zaretskii writes: >> From: Jonas Bernoulli >> Cc: michael.albinus@gmx.de, 71971@debbugs.gnu.org >> Date: Mon, 08 Jul 2024 19:41:16 +0200 >> >> Eli Zaretskii writes: >> >> >> From: Jonas Bernoulli >> >> 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. [[[ Re-reading the message I am responding to, I realize that you are already aware of what I am about to say: > 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. I am leaving it in my response anyway, to make it a bit more explicit. ]]] 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. (with-editor.el also fails to solve that problem either, but that's not what we are discussing here.) > >> 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. Ah sorry, it is "-r"/"--reuse-frame" that was added in Emacs 29.1. The evidence thickens that I should/could just have used "emacsclient -c". I was only trying to reconstruct why I have made the decision to add `with-editor-server-window-alist' back when I did that. It's possible that I didn't realize back then that I could have used "-c" instead. Or it is possible, that I had some good (or otherwise) reason not to do it despite knowing about that argument. >> 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. 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". >> > 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\\)\\'" >> > 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. Without looking up commonly accepted definitions of the term "protocol", I assume(d) that you either meant: 1. The mechanism by which two or more entities exchange information, and/or 2. The kind of values and/or concrete values/"commands", that can be exchanged over said channel. You also said, > Other ideas are welcome. So for (1) I suggested "environment variables" and for (2) "implement switch-to-buffer-new-frame". I'm not saying those are necessarily good suggestions, but that is what came to mind, and they seem at least applicable and should be mentioned in the idea collection phase. >> 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. 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. 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".