Received: (at 71971) by debbugs.gnu.org; 10 Jul 2024 16:33:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 10 12:33:11 2024 Received: from localhost ([127.0.0.1]:57021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sRaFj-0007oS-Ee for submit <at> debbugs.gnu.org; Wed, 10 Jul 2024 12:33:11 -0400 Received: from mail.hostpark.net ([212.243.197.30]:34976) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jonas@HIDDEN>) id 1sRaFg-0007oK-Gg for 71971 <at> debbugs.gnu.org; Wed, 10 Jul 2024 12:33:09 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id EAC2316609; Wed, 10 Jul 2024 18:32:59 +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=1720629179; bh=iUUMekMvkMk/APbTHwveMSK1vpSI7ptzETrN3V7t9QA=; b= ipyBOKyU01LjBX56vyrxV5znWeXzgNr6AWJracoCOAvwTFHQ5itKt/HBPy4vSxhY h2lajzvsVElSD0+15wosh0anUYb3kb5RxJsKL2A2nF57INAwwVWfxY/IQygjJJtH I1KlUNjm52weGDl/BC4dGyn/BCqv4NbT38D04VFzgag= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id TEZjbqtEyygz; Wed, 10 Jul 2024 18:32:59 +0200 (CEST) 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 3F3C216297; Wed, 10 Jul 2024 18:32:57 +0200 (CEST) From: Jonas Bernoulli <jonas@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#71971: 31.0.50; Add user option server-window-alist In-Reply-To: <86cynlo4wz.fsf@HIDDEN> References: <871q463hke.fsf@HIDDEN> <86cynq4vfa.fsf@HIDDEN> <87msmuvc5m.fsf@HIDDEN> <86wmly37c6.fsf@HIDDEN> <871q43vl1f.fsf@HIDDEN> <86y16bzs0w.fsf@HIDDEN> <87wmlutmhs.fsf@HIDDEN> <86cynlo4wz.fsf@HIDDEN> Date: Wed, 10 Jul 2024 18:32:56 +0200 Message-ID: <87ttgxtdfr.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 71971 Cc: michael.albinus@HIDDEN, 71971 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Thanks for the clarifications, I understand better now and agree its a worthwhile goal. Unfortunately I have no idea how to do it, but I look forward to see what you and others come up with. I can't think of anything myself, for now at least. Cheers!
bug-gnu-emacs@HIDDEN:bug#71971; Package emacs.
Full text available.Received: (at 71971) by debbugs.gnu.org; 10 Jul 2024 11:36:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 10 07:36:16 2024 Received: from localhost ([127.0.0.1]:55029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sRVcN-0007b3-VR for submit <at> debbugs.gnu.org; Wed, 10 Jul 2024 07:36:16 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44016) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sRVcL-0007ah-ME for 71971 <at> debbugs.gnu.org; Wed, 10 Jul 2024 07:36:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1sRVc8-00085A-Nr; Wed, 10 Jul 2024 07:36:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=VlO2LyaRAfEoBRzLqvzDb1WLLF7Wi5pub0NMWvQ0764=; b=E9CzerbhRh4g E0OFZMEpV4jlc1+/1MtDPYpqO9aZyykpwqcCvT1oxYYrYODhGY2PKoGoKN/akn4Ehb1g94CKG489I w8NixcEqEdpoYX57vvtDmdcX3MCGnuGHeLqsSWZ2naWnammEepp62PIZ0g6UEHocnZksM5+7D+DV1 WcszRKdqxuQihvPQ8oZzKy+l7uiDBk+MNm34aFHpRqLoym1wIEpb+Nz6emnxodIlXvHMr1cILDEhF VZiyITSHJNsn6qrSLLRgvOLCIoaTzldcCx/C2yWKS6djiwpDsRSekWvDg99w9axAsDRcFcWyC35/3 bF9D8ZZwVUNt52TANNWMXw==; Date: Wed, 10 Jul 2024 14:35:56 +0300 Message-Id: <86cynlo4wz.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Jonas Bernoulli <jonas@HIDDEN> In-Reply-To: <87wmlutmhs.fsf@HIDDEN> (message from Jonas Bernoulli on Tue, 09 Jul 2024 21:05:03 +0200) Subject: Re: bug#71971: 31.0.50; Add user option server-window-alist References: <871q463hke.fsf@HIDDEN> <86cynq4vfa.fsf@HIDDEN> <87msmuvc5m.fsf@HIDDEN> <86wmly37c6.fsf@HIDDEN> <871q43vl1f.fsf@HIDDEN> <86y16bzs0w.fsf@HIDDEN> <87wmlutmhs.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71971 Cc: michael.albinus@HIDDEN, 71971 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Jonas Bernoulli <jonas@HIDDEN> > Cc: michael.albinus@HIDDEN, 71971 <at> debbugs.gnu.org > Date: Tue, 09 Jul 2024 21:05:03 +0200 > > 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. One way of solving this is to set $EDITOR outside Emacs, and set $GIT_EDITOR in process-environment inside Emacs. > > 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". What I meant that it's impossible using the server-window like options. > >> > 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\\)\\'" That's exactly what I thought: to do something like that the user needs to know the possible names of files created by Git (and other VCSes) for editing log messages. Many/most people don't know that, and so will have trouble customizing such options. IOW, the REGEXP part makes this option work on a very low level, and thus less friendly than it could be. > >> > 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. How does server.el know whether to create a new client frame or reuse the current one, and what kind of frame to create? Answer: emacsclient tells it, via the appropriate commands that are part of the emacs server to emacsclient protocol. The protocol is documented in the doc string of server-process-filter. In particular, the command -current-frame tells the server not to create new frames; -tty tells it to create a TTY frame; etc. > > 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. That's unportable. On some systems, environment variables will be inherited by subprocesses of "git commit". > 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". Not when commands (such as emacsclient) are invoked from Emacs by Lisp programs. In that case, it is the Lisp program that must decide which command-line switches of emacsclient to use, and my bothr is how to let users specify that in a way that is both powerful and flexible, and user-friendly. Using regexps that match files or buffers is not user-friendly enough to my palate in this case.
bug-gnu-emacs@HIDDEN:bug#71971; Package emacs.
Full text available.Received: (at 71971) by debbugs.gnu.org; 9 Jul 2024 19:05:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 09 15:05:18 2024 Received: from localhost ([127.0.0.1]:54099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sRG9N-0003VB-FY for submit <at> debbugs.gnu.org; Tue, 09 Jul 2024 15:05:18 -0400 Received: from mail.hostpark.net ([212.243.197.30]:53566) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jonas@HIDDEN>) id 1sRG9J-0003V1-Qu for 71971 <at> debbugs.gnu.org; Tue, 09 Jul 2024 15:05:15 -0400 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 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) 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) From: Jonas Bernoulli <jonas@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#71971: 31.0.50; Add user option server-window-alist In-Reply-To: <86y16bzs0w.fsf@HIDDEN> References: <871q463hke.fsf@HIDDEN> <86cynq4vfa.fsf@HIDDEN> <87msmuvc5m.fsf@HIDDEN> <86wmly37c6.fsf@HIDDEN> <871q43vl1f.fsf@HIDDEN> <86y16bzs0w.fsf@HIDDEN> Date: Tue, 09 Jul 2024 21:05:03 +0200 Message-ID: <87wmlutmhs.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 71971 Cc: michael.albinus@HIDDEN, 71971 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Jonas Bernoulli <jonas@HIDDEN> >> Cc: michael.albinus@HIDDEN, 71971 <at> debbugs.gnu.org >> Date: Mon, 08 Jul 2024 19:41:16 +0200 >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> >> From: Jonas Bernoulli <jonas@HIDDEN> >> >> 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. [[[ 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".
bug-gnu-emacs@HIDDEN:bug#71971; Package emacs.
Full text available.Received: (at 71971) by debbugs.gnu.org; 8 Jul 2024 17:57:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 08 13:57:05 2024 Received: from localhost ([127.0.0.1]:51471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sQsbp-0003Uk-Be for submit <at> debbugs.gnu.org; Mon, 08 Jul 2024 13:57:05 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47942) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sQsbm-0003UF-OE for 71971 <at> debbugs.gnu.org; Mon, 08 Jul 2024 13:57:03 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1sQsbb-0003MW-5W; Mon, 08 Jul 2024 13:56:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=styk+fisHiG2kdjBtS7atJg3s6re7CIiIsN8ZjqkeWo=; b=qeWg7Q8GY97A xr2ugzbtM+5LdSEAtpdmX4L9BVkmZSL6gDdqg+a0EQE4gClqENVF9Slr0cMaFVW7quqnAgKUSJnMi Vf+iG/Nw02r3GWlQM3dGCmBpII1KkFACaHRtr2W/ASQB64KNTIXmXcm+eYMKRoUk0bmf1ZRrm9EpT VYnZAjk8uvGlMIT0tyHHW3qrYM2s6GSerianKFdevZmBF6q+AiU+gWy/QipLPKw/F2wT5PH4KM7ns igiOC10amUHnap3YM1RHtVQ+e8bIE5okyVXWkOQb0byz0ML1OGPxriF80C3phiAyW2r/qt80WkqDL /+rRTcrI6v/OLS2I5UwA/Q==; Date: Mon, 08 Jul 2024 20:56:47 +0300 Message-Id: <86y16bzs0w.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Jonas Bernoulli <jonas@HIDDEN> In-Reply-To: <871q43vl1f.fsf@HIDDEN> (message from Jonas Bernoulli on Mon, 08 Jul 2024 19:41:16 +0200) Subject: Re: bug#71971: 31.0.50; Add user option server-window-alist References: <871q463hke.fsf@HIDDEN> <86cynq4vfa.fsf@HIDDEN> <87msmuvc5m.fsf@HIDDEN> <86wmly37c6.fsf@HIDDEN> <871q43vl1f.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71971 Cc: michael.albinus@HIDDEN, 71971 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Jonas Bernoulli <jonas@HIDDEN> > Cc: michael.albinus@HIDDEN, 71971 <at> debbugs.gnu.org > Date: Mon, 08 Jul 2024 19:41:16 +0200 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> From: Jonas Bernoulli <jonas@HIDDEN> > >> 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.
bug-gnu-emacs@HIDDEN:bug#71971; Package emacs.
Full text available.Received: (at 71971) by debbugs.gnu.org; 8 Jul 2024 17:41:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 08 13:41:31 2024 Received: from localhost ([127.0.0.1]:51420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sQsMk-00035k-Pm for submit <at> debbugs.gnu.org; Mon, 08 Jul 2024 13:41:31 -0400 Received: from mail.hostpark.net ([212.243.197.30]:53480) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jonas@HIDDEN>) id 1sQsMh-00035U-3l for 71971 <at> debbugs.gnu.org; Mon, 08 Jul 2024 13:41:29 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id A4B2C164D4; Mon, 8 Jul 2024 19:41:19 +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=1720460479; bh=t8onZXusdGQRnIocJTx289OpA/W6eS8m3wYoiTZR0VE=; b= TRG6u7h2kKVeO/ogzsEWWvVbyFtJMXBm4MNDKQNgou61OVZODCD3WJFNZ7mQAjBK XUAPt1QZiPJmybmlhHH95GEddDtd2WTxFz13sMCJu/8w6n3qnD2cIn6ITDXctQeV kFm1DWoIUKt4robuJt20RvubBYtG1dJV0DkaTE9eWKE= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net 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 AXrGQqudFKHP; Mon, 8 Jul 2024 19:41:19 +0200 (CEST) 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 ECA4616463; Mon, 8 Jul 2024 19:41:17 +0200 (CEST) From: Jonas Bernoulli <jonas@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#71971: 31.0.50; Add user option server-window-alist In-Reply-To: <86wmly37c6.fsf@HIDDEN> References: <871q463hke.fsf@HIDDEN> <86cynq4vfa.fsf@HIDDEN> <87msmuvc5m.fsf@HIDDEN> <86wmly37c6.fsf@HIDDEN> Date: Mon, 08 Jul 2024 19:41:16 +0200 Message-ID: <871q43vl1f.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 71971 Cc: michael.albinus@HIDDEN, 71971 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Jonas Bernoulli <jonas@HIDDEN> >> 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? Where? --- 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, 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. > IOW, > what you describe involves workflows some of which want a new client > frame and some want to reuse the same frame. Yes. > 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? Oh, I see, there's no switch-to-buffer-new-frame, just switch-to-buffer-other-frame. So I think what happened is that "committing from Magit" needed a way the override a universal user preference of "something other than the default of server-window=nil" to go back to "server-window=nil". And then implemented it in a way that could potentially be useful for other packages, without realizing that other pieces that would make that actually useful (such as the new-frame function) weren't actually available. As I said before, had --create-frame been available, I would probably have used that. That being said, maybe adding switch-to-buffer-new-frame wouldn't be such a bad idea. > 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. Other packages could also add their package-specific defaults to the alist. Users could edit these elements. Users could also express their own preferences for specific files that they want to handle differently, and whose names they are well aware of. I don't know whether anyone would want that. I am not doing it. As I said, I might have over generalized it and added a feature nobody actually uses. > 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. Now that we have not only --tty and --reuse-frame but also --create-frame, I personally don't need anything more. But that of course doesn't mean that I cannot imagine that others (including future me) might not want more options. It's worth considering what else could be offered. > 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? 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".
bug-gnu-emacs@HIDDEN:bug#71971; Package emacs.
Full text available.Received: (at 71971) by debbugs.gnu.org; 6 Jul 2024 14:48:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 06 10:48:09 2024 Received: from localhost ([127.0.0.1]:46535 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sQ6ht-000327-5L for submit <at> debbugs.gnu.org; Sat, 06 Jul 2024 10:48:09 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33514) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sQ6hr-00031a-3N for 71971 <at> debbugs.gnu.org; Sat, 06 Jul 2024 10:48:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1sQ6hg-0004W3-Q4; Sat, 06 Jul 2024 10:47:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=vtS19Caq5opWfsefWKswREqWQE90eH1nw0Qzbyq2V84=; b=RCDs64BknwRP dQzz+PUQmXZYJt+GnkjTifb8IqcjAKwlUXqfvMzEAooLR0CgNYhoIbPFN8JlyjPqv2HhJKq1PQ1lz J5Ug0R9F0DB2M7JrzqYr5+AWGlkaeReSFNoLdYF/m6sPNrKOJFAMArCHnkVM1nmDNKU/nq3QzMbPJ NSACjHA8J0NpmRXhgkWibKr3HxjsKQFU0ox9HK0un3a+6zhFpkTRn9R2fmHa6YKJ7J9s2mtNNQMyM MGqfB5RxRVDNBVpsTLmyP8clNrmY2dloI8t2lmIRYg3Bf8yIg0CnFRvYiphd24he6lLCNX2NfFY/p GLKfIeMHQfkJ7t/JjKQkJw==; Date: Sat, 06 Jul 2024 17:47:53 +0300 Message-Id: <86wmly37c6.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Jonas Bernoulli <jonas@HIDDEN> In-Reply-To: <87msmuvc5m.fsf@HIDDEN> (message from Jonas Bernoulli on Sat, 06 Jul 2024 16:16:21 +0200) Subject: Re: bug#71971: 31.0.50; Add user option server-window-alist References: <871q463hke.fsf@HIDDEN> <86cynq4vfa.fsf@HIDDEN> <87msmuvc5m.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71971 Cc: michael.albinus@HIDDEN, 71971 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Jonas Bernoulli <jonas@HIDDEN> > 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"? 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.
bug-gnu-emacs@HIDDEN:bug#71971; Package emacs.
Full text available.Received: (at 71971) by debbugs.gnu.org; 6 Jul 2024 14:16:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 06 10:16:35 2024 Received: from localhost ([127.0.0.1]:46523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sQ6DK-0002DH-MT for submit <at> debbugs.gnu.org; Sat, 06 Jul 2024 10:16:35 -0400 Received: from mail.hostpark.net ([212.243.197.30]:53328) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jonas@HIDDEN>) id 1sQ6DH-0002D5-CD for 71971 <at> debbugs.gnu.org; Sat, 06 Jul 2024 10:16:32 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id D83DD164DA; Sat, 6 Jul 2024 16:16:25 +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=1720275385; bh=pyxSclIVtm6ebhr5bE8UkoFbyfjr6XY2Xsu4ABLcr6U=; b= oTXF7p48KksQfl1F74Ad6mQyPUBVbR1uLSgfRyujHLg8uuIOVd9Y4kYBozj7WODS ifz9vx9eF4MJKEfAeC0jPuHqZCl6iLjwwrQP8kKhNdV5wso9lz7TXT0uGKCZOL0k 9IbbWsB9fneS45pRM/xk3U6zrte4ZGxZCLT+2cQLdsI= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net 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 J24uHWcQp-c5; Sat, 6 Jul 2024 16:16:25 +0200 (CEST) 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 08ED0164CE; Sat, 6 Jul 2024 16:16:23 +0200 (CEST) From: Jonas Bernoulli <jonas@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN>, Michael Albinus <michael.albinus@HIDDEN> Subject: Re: bug#71971: 31.0.50; Add user option server-window-alist In-Reply-To: <86cynq4vfa.fsf@HIDDEN> References: <871q463hke.fsf@HIDDEN> <86cynq4vfa.fsf@HIDDEN> Date: Sat, 06 Jul 2024 16:16:21 +0200 Message-ID: <87msmuvc5m.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 71971 Cc: 71971 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> Cc: Jonas Bernoulli <jonas@HIDDEN> >> 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@HIDDEN> >> >> 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.
bug-gnu-emacs@HIDDEN:bug#71971; Package emacs.
Full text available.
Received: (at 71971) by debbugs.gnu.org; 6 Jul 2024 11:59:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 06 07:59:14 2024
Received: from localhost ([127.0.0.1]:45702 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sQ44P-0006l1-Sp
for submit <at> debbugs.gnu.org; Sat, 06 Jul 2024 07:59:14 -0400
Received: from mout.gmx.net ([212.227.15.19]:41773)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <michael.albinus@HIDDEN>) id 1sQ44O-0006kn-CP
for 71971 <at> debbugs.gnu.org; Sat, 06 Jul 2024 07:59:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de;
s=s31663417; t=1720267140; x=1720871940; i=michael.albinus@HIDDEN;
bh=N+q2q1w9Z26USngaCgGFXLzVsDBXqrqWkynCVNieiW8=;
h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date:
Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:cc:
content-transfer-encoding:content-type:date:from:message-id:
mime-version:reply-to:subject:to;
b=U5VDfLPiBkdnKYYzkh1zn6DafzE9oecpHixBLxNeUpxNQ6PP0rqcirKaeMPa57EE
Ey0CIm8FOx1YZtO0H0yESt9prXImrB4Q3wGHLMF0WYUfvZUBYrkKBwAq2i6XjHz9g
BtY/ksX5mmH+pCwadgnE6D/aIkgbnKhatShgQrH7d032PKsJAJxDkAV8ivwk7xQLk
6LRJugJfSw+Rc516cR/Sb8WUCDXU8bTTdNkF5h3F2NjCZES9RKj/evLo9CsZRi0ua
GYNaEmet8FH2O/P5N0ZnukV04nHbuXkJDk/hE5uUAFMLs1JTst1A5NvGZde8SWy76
YsU4d/8X0Gg8EyB0rw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from gandalf.gmx.de ([185.89.38.155]) by mail.gmx.net (mrgmx004
[212.227.17.190]) with ESMTPSA (Nemesis) id 1N4QsO-1sJ5qE3HeA-00zf9U; Sat, 06
Jul 2024 13:59:00 +0200
From: Michael Albinus <michael.albinus@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#71971: 31.0.50; Add user option server-window-alist
In-Reply-To: <86cynq4vfa.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 06 Jul
2024 14:22:17 +0300")
References: <871q463hke.fsf@HIDDEN> <86cynq4vfa.fsf@HIDDEN>
Date: Sat, 06 Jul 2024 13:58:59 +0200
Message-ID: <87jzhy20l8.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:IhcxS4TlXfBk3/9Qnhy0+jG09iohmVkti9NuD3685ei/fGzzU4u
AyVw0pGXlw8sB5rDREz86ymVUpeDu4uU+dr88+scJV1iBusdzE8F2E2KKAmCXxYGZgUZFep
eBYxCPugUZNhwkjSsuaF0vyKQD0mIoR/GSp2i81ss0GImLjltYIND+4m7La5klSlJr0CqBE
pNFnZTZt9j2fpRXIdfyeg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:/Gr9OIz2aYg=;bz4Z0z0742KEJ+QhewOO0O2uzhF
IEmPokLL5mYtomNc6Fh9kf0/vWwSKM9bfbH5Zd1/9POpkrK+45BWzHsYkzWB/tylWag+Vp+x3
UbcnGbsz3O+q0gxnZ01m7XLLg0FzlGD8/RI63d7Z3HcikyCk65gD9RxiuyBwSwJj9OBPQQBqp
vTepGhMlrlXyifbc/3zNQ3B9aGej1T2DQ1k9GRIuLHsNl7yWXiEA4GpwixokKYu0DCmeKi0Ha
qBChW2UnE6vdAyNoeJ1jgl8KhFdYx0+Sfj8BfuWAyF+FFbhCDsFdoGxvD1yrJr+0uR8MrjMar
E/wddoGJi6gkLJCN95lzMLOq5y5C9wBoOhKULd0gEX17zeGpJbMIRmJSMj8gzqd/0UNvLs1RQ
qk82jx+IQnAxGFC8CFqhGtD3Kisj4HXV+cZ4TLhrBccBJoahDcJlNsD1ZzqPWfkkYp/DNaMRp
g2saNtaINaLjbaAiFqfUdK8awNIvHgy+tH1LHMF1NDxHZmK7nvl6HqXO5JGVBY/ciFqb1OZci
rldksVkfkIos6hY/BvZm3xayLMlFdfhTXOY6VdNk4hmG3Ln9MitnYgKw8JZpgokmlPDYKNfBy
eK0ZGjMqmc7w1PFJYXUiDt6XgILAesdZKXIcDpLN1hK6nSb94hQxf5IPjajC0VVQM/msO5BvU
x4Ay1b56ct8fge1bS2h/QOAB1x4AMDvAhEHj5OuBg8YjIGKtd4RIunXs36pvryBVqyIgGXATm
i1bycTFENmgMB6tDdMApSmPuKWnqJ5+YRUiTc434iE3wR5IhvyJL2Ga6yTiqpry3LM4wYejTN
iVlurhjoLGSEqs1kSzXp+cTfWgBRUYQuswlZkO5gdG16U=
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii writes: Hi Eli,
>> 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 matc [...]
Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[185.89.38.155 listed in zen.spamhaus.org]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.15.19 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (michael.albinus[at]gmx.de)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
X-Debbugs-Envelope-To: 71971
Cc: jonas@HIDDEN, 71971 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii writes: Hi Eli, >> 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 matc [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.15.19 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[185.89.38.155 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (michael.albinus[at]gmx.de)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
Eli Zaretskii <eliz@HIDDEN> writes:
Hi Eli,
>> A new user option `server-window-alist' shall be added to server.el. Ev=
ery
>> entry shall be of type (REGEXP . SERVER-WINDOW). REGEXP is used to filt=
er
>> 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.)
I would let this to Jonas. Perhaps a short description which would be
good for "(emacs) Invoking emacsclient".
> Thanks.
Best regards, Michael.
bug-gnu-emacs@HIDDEN:bug#71971; Package emacs.
Full text available.Received: (at 71971) by debbugs.gnu.org; 6 Jul 2024 11:22:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 06 07:22:32 2024 Received: from localhost ([127.0.0.1]:45688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sQ3Uu-0002sa-Jb for submit <at> debbugs.gnu.org; Sat, 06 Jul 2024 07:22:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55832) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sQ3Us-0002sO-Vo for 71971 <at> debbugs.gnu.org; Sat, 06 Jul 2024 07:22:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1sQ3Ui-0007ht-Uv; Sat, 06 Jul 2024 07:22:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=TGPJU1mmLv43kAKcxBwvs8OlH+VNg2Fo/TdcQYFrzPk=; b=Wdi/cy2qTfWX UW2132uQy0ebldxXF+jemM8SPzg+oKhzEYzSrvMJTIBflqTFDWaSEPmtLlId3TSuOzyyciHXQw7y7 pq6TwV2CiOeHBVdbn0RqHD308TqQEE9OTMSnUWjeCnPOwbTD52qKhtp8m8kN2GuwFy48aICDisgaL YEhxKCp95Sdu3rY5ZBwAx7uiwL0m6xh6fpJTv0nI2kXjuD/fDh9aal1lEfC79VJe1ogSzdrcRkptu eZMjDgoP8Zlubm+P0fZgblDqhYJx3j3gDTTCCBtOgfEhOhSWpZaULLS1O80cZWa73CZHWp+1yRaDZ AQ0J9Umy1zr/NdhvYkNA/Q==; Date: Sat, 06 Jul 2024 14:22:17 +0300 Message-Id: <86cynq4vfa.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Michael Albinus <michael.albinus@HIDDEN> In-Reply-To: <871q463hke.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#71971: 31.0.50; Add user option server-window-alist References: <871q463hke.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71971 Cc: jonas@HIDDEN, 71971 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: Jonas Bernoulli <jonas@HIDDEN> > 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@HIDDEN> > > 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.) Thanks.
bug-gnu-emacs@HIDDEN:bug#71971; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 6 Jul 2024 11:07:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 06 07:07:10 2024
Received: from localhost ([127.0.0.1]:45668 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sQ3G1-0002TS-2O
for submit <at> debbugs.gnu.org; Sat, 06 Jul 2024 07:07:09 -0400
Received: from lists.gnu.org ([209.51.188.17]:44198)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <michael.albinus@HIDDEN>) id 1sQ3Fy-0002TK-6t
for submit <at> debbugs.gnu.org; Sat, 06 Jul 2024 07:07:07 -0400
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 <michael.albinus@HIDDEN>)
id 1sQ3Ft-0006Jy-SD
for bug-gnu-emacs@HIDDEN; Sat, 06 Jul 2024 07:07:02 -0400
Received: from mout.gmx.net ([212.227.15.19])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <michael.albinus@HIDDEN>)
id 1sQ3Fr-0007YS-55
for bug-gnu-emacs@HIDDEN; Sat, 06 Jul 2024 07:07:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de;
s=s31663417; t=1720264017; x=1720868817; i=michael.albinus@HIDDEN;
bh=fuxOpGF2AxIC4EWj2NFuBtTdgX20fGG3p/7kFUW+dg8=;
h=X-UI-Sender-Class:From:To:Subject:Date:Message-ID:MIME-Version:
Content-Type:cc:content-transfer-encoding:content-type:date:from:
message-id:mime-version:reply-to:subject:to;
b=SMrMIELf8FIX/xcasXsvbgEBGm90CcIR965w55/HpzFdTeauXhHh7U+/uWHZPkQm
fEycFJsu1zHNgMNr1gCU2ZkKKN/6LXBKsQbQzmnVzv1CHsrW/YbbdgGzDYrIjN9AS
NhM18NKwf4U4IMHyt2+DbmVCyBP391HdUJCUTJhlk2bSz+TebfeA7RMdqhpqqUsNb
scNPLi+qZoF9p+cfrhvTq5D+Q7hk+jQqk6AWVj9svDteVEmZCHp7pBIqklzv2PYCv
pMtVY8kUedDY8cgmJHBC/oHYVZ3SgAzg2g6h6Jp2Y22lA6HB/Nm/ptQeP18hASehU
m22SOmeLgK2aSqiIrQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from gandalf.gmx.de ([185.89.38.155]) by mail.gmx.net (mrgmx004
[212.227.17.190]) with ESMTPSA (Nemesis) id 1N8ob6-1sNUNL2RVO-0141wH for
<bug-gnu-emacs@HIDDEN>; Sat, 06 Jul 2024 13:06:57 +0200
From: Michael Albinus <michael.albinus@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; Add user option server-window-alist
User-Agent: Gnus/5.13 (Gnus v5.13)
X-Debbugs-Cc: Jonas Bernoulli <jonas@HIDDEN>
Date: Sat, 06 Jul 2024 13:06:57 +0200
Message-ID: <871q463hke.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:G3+LrIzPzP52yudD0w9F/bXPNQ5qa5yUosbPwaeqhtd639ySToe
7j/tSmnUT6U7Uv2f/5cad54xlvPEmeS5Z4vUk40Tkq3s7HAjDTPgpS7W9RPuJSYVbc0aH3h
3zWKC5mG7paV2hJ3HS8yVsyuD6/krkxeTu+FHGzx4VhE5o+IkRHzdsmq4zoZF75DH6SRqQj
In7CtU1nCQXpyu41y5+1g==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:vRnP4AIVNfE=;2WAHWun/KT3k1YTwDXg9JfmJS0r
hUaGCSbBNC4gcJIBTNKHVcwEOftPdOY6UYU+Cwd4Q0KK2FBB4Dta4z29Enm9Sdy3UmdilmkSo
SDE5LOuj9u/qBbvcmGC3nFFm/0y1Il16xTpPW3ZiyRPsTbCTLZDOUFM2aOsDyriTP0wENMLPN
qHRAlPIjURdMb8/zF8VNX7/DpsksKThSIbflv9StAbmwI8znKd7W1nh+qskaf9srcSaE2PAmV
dcyUUgN39SVMHm1jX7hclcu6xb+F2nRXFRxt9pcbX718/mvOyGIvRevPr445NLivtGl1JoQXS
RWMaVzUEE9Ic5i0rguzZ26xQrxY9cw0/YoWO/GlC2DnNMp/ybxG2IPfTFoZZQWflRpC5isZ/u
EHOMQiMq3syjX/+7fvGL5348buuT16gdR/dsGJQx4YExh/eg07VzhF/9PnSBh6hIpHktGLpZj
VwJMlkVttEoi0ewnuWZuFHkkdsvlDzX5rmgCkEzQsjpLyItVSGlm6/WH+zavdoncNqtF9xqGy
ZptpD5HHYpxMELJtTbFDFGYqlam6RsifzoYl6GLi6oxwz2RQctZKF7h1oEL3oqTIQE4cGCIDB
E1D0Q/Xzgh+/jo+sOaLfDYWpPCAk7+wb7JZkBT6o6OMpqmlgLCFz3Papjq45hAjEeI3C0qzcc
cNQk2tL9rn4Ncotnt3vbKbUnk/AH8o3b3kx6IEY9Yfb6ShAWMFJfXl4GkZjsABTSJcjwGQBnG
w+JUBuvJc42yoXkzBgGUNrIctgU1ZGgN7/EVwYgwObQ2D0MujY1k2fmUb3spjQOY2vbg6b9Gz
ZPXwi+CZKm61mrBt9/ARls4G1t6g8ZL44wUOqoTdWY70Q=
Received-SPF: pass client-ip=212.227.15.19;
envelope-from=michael.albinus@HIDDEN; helo=mout.gmx.net
X-Spam_score_int: 5
X-Spam_score: 0.5
X-Spam_bar: /
X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Severity: wishlist 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, SERV
[...] Content analysis details: (2.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[185.89.38.155 listed in zen.spamhaus.org]
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/,
medium trust [209.51.188.17 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (michael.albinus[at]gmx.de)
1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
0.0 SPOOFED_FREEMAIL No description available.
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Severity: wishlist 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, SERV
[...]
Content analysis details: (1.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/,
medium trust
[209.51.188.17 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[185.89.38.155 listed in zen.spamhaus.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (michael.albinus[at]gmx.de)
1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
Severity: wishlist
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.
In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.42, cairo version 1.18.0) of 2024-06-30 built on gandalf
Repository revision: c6a052f2fe53a26cdb0f3624a0b9af5201f3c487
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12401000
System Description: Fedora Linux 40 (Workstation Edition)
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LIBOTF LIBSELINUX LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8
Major mode: ELisp/l
Minor modes in effect:
display-time-mode: t
delete-selection-mode: t
icomplete-mode: t
global-goto-address-mode: t
goto-address-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
buffer-read-only: t
column-number-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/home/albinus/src/elpa/packages/debbugs/debbugs hides /home/albinus/.emacs.d/elpa/debbugs-0.40/debbugs
/home/albinus/src/elpa/packages/debbugs/debbugs-org hides /home/albinus/.emacs.d/elpa/debbugs-0.40/debbugs-org
/home/albinus/src/elpa/packages/debbugs/debbugs-gnu hides /home/albinus/.emacs.d/elpa/debbugs-0.40/debbugs-gnu
/home/albinus/src/elpa/packages/debbugs/debbugs-guix hides /home/albinus/.emacs.d/elpa/debbugs-0.40/debbugs-guix
/home/albinus/src/elpa/packages/debbugs/debbugs-browse hides /home/albinus/.emacs.d/elpa/debbugs-0.40/debbugs-browse
/home/albinus/src/elpa/packages/debbugs/debbugs-pkg hides /home/albinus/.emacs.d/elpa/debbugs-0.40/debbugs-pkg
/home/albinus/src/elpa/packages/debbugs/debbugs-autoloads hides /home/albinus/.emacs.d/elpa/debbugs-0.40/debbugs-autoloads
/home/albinus/src/elpa/packages/debbugs/debbugs-compat hides /home/albinus/.emacs.d/elpa/debbugs-0.40/debbugs-compat
/home/albinus/.emacs.d/elpa/helm-3.9.9/helm-packages hides /home/albinus/.emacs.d/elpa/helm-core-3.9.9/helm-packages
~/lisp/telepathy hides /home/albinus/.emacs.d/elpa/telepathy-20131209.1258/telepathy
/home/albinus/src/elpa/packages/tramp-theme/tramp-theme-autoloads hides /home/albinus/.emacs.d/elpa/tramp-theme-0.2/tramp-theme-autoloads
/home/albinus/src/elpa/packages/tramp-theme/tramp-theme hides /home/albinus/.emacs.d/elpa/tramp-theme-0.2/tramp-theme
/home/albinus/src/elpa/packages/tramp-theme/tramp-theme-pkg hides /home/albinus/.emacs.d/elpa/tramp-theme-0.2/tramp-theme-pkg
/home/albinus/.emacs.d/elpa/hydra-0.15.0/lv hides /home/albinus/.emacs.d/elpa/lv-0.15.0/lv
/home/albinus/.emacs.d/elpa/transient-20240626.947/transient hides /usr/local/share/emacs/31.0.50/lisp/transient
/home/albinus/.emacs.d/elpa/idlwave-6.5.1/idlwave hides /usr/local/share/emacs/31.0.50/lisp/progmodes/idlwave
/home/albinus/.emacs.d/elpa/idlwave-6.5.1/idlw-shell hides /usr/local/share/emacs/31.0.50/lisp/progmodes/idlw-shell
/home/albinus/.emacs.d/elpa/idlwave-6.5.1/idlw-toolbar hides /usr/local/share/emacs/31.0.50/lisp/progmodes/idlw-toolbar
/home/albinus/.emacs.d/elpa/idlwave-6.5.1/idlw-complete-structtag hides /usr/local/share/emacs/31.0.50/lisp/progmodes/idlw-complete-structtag
/home/albinus/.emacs.d/elpa/idlwave-6.5.1/idlw-help hides /usr/local/share/emacs/31.0.50/lisp/progmodes/idlw-help
~/lisp/dbus hides /usr/local/share/emacs/31.0.50/lisp/net/dbus
/home/albinus/src/tramp/lisp/tramp-sh hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-sh
/home/albinus/src/tramp/lisp/tramp-fuse hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-fuse
/home/albinus/src/tramp/lisp/tramp-androidsu hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-androidsu
/home/albinus/src/tramp/lisp/tramp-loaddefs hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-loaddefs
/home/albinus/src/tramp/lisp/tramp-ftp hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-ftp
/home/albinus/src/tramp/lisp/tramp hides /usr/local/share/emacs/31.0.50/lisp/net/tramp
/home/albinus/src/tramp/lisp/tramp-cache hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-cache
/home/albinus/src/tramp/lisp/tramp-uu hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-uu
/home/albinus/src/tramp/lisp/tramp-rclone hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-rclone
/home/albinus/src/tramp/lisp/tramp-integration hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-integration
/home/albinus/src/tramp/lisp/tramp-archive hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-archive
/home/albinus/src/tramp/lisp/tramp-adb hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-adb
/home/albinus/src/tramp/lisp/tramp-cmds hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-cmds
/home/albinus/src/tramp/lisp/tramp-compat hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-compat
/home/albinus/src/tramp/lisp/tramp-sudoedit hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-sudoedit
/home/albinus/src/tramp/lisp/tramp-container hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-container
/home/albinus/src/tramp/lisp/tramp-gvfs hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-gvfs
/home/albinus/src/tramp/lisp/tramp-crypt hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-crypt
/home/albinus/src/tramp/lisp/tramp-message hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-message
/home/albinus/src/tramp/lisp/tramp-smb hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-smb
/home/albinus/src/tramp/lisp/trampver hides /usr/local/share/emacs/31.0.50/lisp/net/trampver
/home/albinus/src/tramp/lisp/tramp-sshfs hides /usr/local/share/emacs/31.0.50/lisp/net/tramp-sshfs
/home/albinus/.emacs.d/elpa/faceup-20170925.1946/faceup hides /usr/local/share/emacs/31.0.50/lisp/emacs-lisp/faceup
Features:
(shadow warnings emacsbug mule-util display-line-numbers pulse vc-git
diff-mode track-changes easy-mmode find-dired xref project grep
dired-aux cl-print server help-fns radix-tree misearch multi-isearch
time-stamp url-http url-gw url-auth url-cache shr-color color compile
comp-run comp-common oc-basic org-element org-persist org-id org-refile
org-element-ast inline avl-tree generator ol-eww eww url-queue mm-url
ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect ol-docview doc-view
filenotify image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m ol-doi
org-link-doi org org-macro org-pcomplete org-list org-footnote org-faces
org-entities noutline outline ob-emacs-lisp org-table org-loaddefs
find-func cal-menu calendar cal-loaddefs flow-fill cl-extra sort smiley
gnus-cite mm-archive mail-extr gnus-bcklg textsec uni-scripts
idna-mapping ucs-normalize uni-confusable textsec-check gnus-async qp
gnus-ml debbugs-browse bug-reference disp-table pop3 nndraft nnmh
network-stream nsm nnml gnus-agent gnus-srvr gnus-score score-mode
nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls
dig gnus-cache gnus-sum shr pixel-fill kinsoku url-file svg dom nnnil
nntp gnus-group gnus-undo smtpmail gnus-start gnus-dbus dbus xml
gnus-cloud nnimap nnmail mail-source utf7 nnoo gnus-spec gnus-int
gnus-range message sendmail yank-media puny rfc822 mml mml-sec epa
derived epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader
gnus-win gnus nnheader gnus-util text-property-search mail-utils range
mm-util mail-prsvr face-remap ob-shell ob ob-tangle ol org-src sh-script
smie treesit executable ob-ref ob-lob ob-table ob-exp ob-comint ob-core
org-cycle org-fold org-fold-core ob-eval org-keys oc org-compat
org-version org-macs vc vc-dispatcher time tramp-sh lxc-tramp lxd-tramp
tramp trampver tramp-integration files-x tramp-message help-mode
tramp-compat xdg shell pcomplete comint ansi-osc ring parse-time iso8601
time-date format-spec ansi-color tramp-loaddefs rx delsel ido jka-compr
icomplete cus-edit pp cus-load wid-edit dired dired-loaddefs goto-addr
thingatpt alert-autoloads android-mode-autoloads
auth-source-gopass-autoloads auth-source-keytar-autoloads
auth-source-kwallet-autoloads auth-source-xoauth2-autoloads
auto-sudoedit-autoloads auto-virtualenv-autoloads
auto-virtualenvwrapper-autoloads boxquote-autoloads
clang-format-autoloads company-shell-autoloads company-autoloads
counsel-toki-autoloads counsel-tramp-autoloads counsel-autoloads
dbus-codegen-autoloads debbugs-autoloads dired-du-autoloads
dired-rsync-autoloads dired-toggle-sudo-autoloads direnv-autoloads
disk-usage-autoloads dockerfile-mode-autoloads drepl-autoloads
comint-mime-autoloads editorconfig-charset-extras-autoloads
editorconfig-custom-majormode-autoloads
editorconfig-domain-specific-autoloads editorconfig-generate-autoloads
ednc-autoloads el-get-autoloads envrc-autoloads
etc-sudoers-mode-autoloads exec-path-from-shell-autoloads
faceup-autoloads fontaine-autoloads forge-autoloads closql-autoloads
emacsql-autoloads friendly-tramp-path-autoloads fzf-autoloads
ggtags-autoloads ghub-autoloads gited-autoloads
gitlab-ci-mode-flycheck-autoloads gitlab-ci-mode-autoloads
flycheck-autoloads gntp-autoloads helm-gitlab-autoloads
helm-projectile-autoloads helm-autoloads helm-core-autoloads
async-autoloads ibuffer-tramp-autoloads idlwave-autoloads
inheritenv-autoloads ivy-gitlab-autoloads gitlab-autoloads
journalctl-mode-autoloads keepass-mode-autoloads keytar-autoloads
kubernetes-autoloads log4e-autoloads lsp-java-autoloads
dap-mode-autoloads lsp-docker-autoloads bui-autoloads
lsp-latex-autoloads consult-autoloads lsp-treemacs-autoloads
lsp-mode-autoloads f-autoloads lxc-tramp-autoloads lxd-tramp-autoloads
magit-filenotify-autoloads magit-autoloads pcase git-commit-autoloads
magit-popup-autoloads magit-section-autoloads marcopolo-autoloads
mastodon-autoloads nexus-autoloads oauth2-autoloads
ob-restclient-autoloads orderless-autoloads password-menu-autoloads
persist-autoloads pkg-info-autoloads epl-autoloads popup-autoloads
projectile-autoloads promise-autoloads pylint-autoloads
python-environment-autoloads deferred-autoloads pyvenv-autoloads
recentf-remove-sudo-tramp-prefix-autoloads request-autoloads
restclient-test-autoloads restclient-autoloads s3ed-autoloads
shell-maker-autoloads finder-inf slime-autoloads macrostep-autoloads
spinner-autoloads ssh-deploy-autoloads su-autoloads sudo-edit-autoloads
sudo-ext-autoloads sudo-utils-autoloads swiper-autoloads ivy-autoloads
sx-autoloads markdown-mode-autoloads telepathy-autoloads totp-autoloads
totp-auth-autoloads base32-autoloads tramp-nspawn-autoloads
tramp-theme-autoloads transient-dwim-autoloads transient-autoloads
treemacs-autoloads cfrs-autoloads posframe-autoloads ht-autoloads
pfuture-autoloads ace-window-autoloads avy-autoloads treepy-autoloads
uuid-autoloads vdiff-autoloads hydra-autoloads lv-autoloads
vertico-autoloads virtualenv-autoloads virtualenvwrapper-autoloads
s-autoloads dash-autoloads web-server-autoloads wfnames-autoloads info
with-editor-autoloads yaml-autoloads yaml-mode-autoloads package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs icons
password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk
x-toolkit xinput2 x multi-tty move-toolbar make-network-process
native-compile emacs)
Memory information:
((conses 16 1748804 228839)
(symbols 48 31304 4)
(strings 32 249486 10542)
(string-bytes 1 13799666)
(vectors 16 90231)
(vector-slots 8 1118851 332769)
(floats 8 635 8034)
(intervals 56 143328 285)
(buffers 992 37))
Michael Albinus <michael.albinus@HIDDEN>:jonas@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.jonas@HIDDEN, bug-gnu-emacs@HIDDEN:bug#71971; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.