Received: (at 70949) by debbugs.gnu.org; 31 May 2024 06:20:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 31 02:20:12 2024
Received: from localhost ([127.0.0.1]:53015 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sCvca-0001kI-3P
for submit <at> debbugs.gnu.org; Fri, 31 May 2024 02:20:12 -0400
Received: from relay1-d.mail.gandi.net ([217.70.183.193]:43833)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1sCvcW-0001jv-Qk
for 70949 <at> debbugs.gnu.org; Fri, 31 May 2024 02:20:10 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id CA3B8240008;
Fri, 31 May 2024 06:19:50 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#70949: display-buffer-choose-some-window
In-Reply-To: <becd5819-6b15-422a-ba4f-106c03a04bbd@HIDDEN> (martin rudalics's
message of "Thu, 30 May 2024 10:54:35 +0200")
Organization: LINKOV.NET
References: <86jzjwqqmd.fsf@HIDDEN> <867cft0xt2.fsf@HIDDEN>
<ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN>
<86ed9xvz3o.fsf@HIDDEN>
<73251208-1e4c-4231-ae58-faf82363f241@HIDDEN>
<86jzjoo23l.fsf@HIDDEN>
<9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN>
<86cypfm6s7.fsf@HIDDEN>
<d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN>
<86o78xm9y5.fsf@HIDDEN>
<78dfee56-80b4-4ba7-a012-df31abd21743@HIDDEN>
<86sey8jv66.fsf@HIDDEN>
<f9970431-325e-44b0-b959-ed9839d7ba47@HIDDEN>
<86zfsfqgtl.fsf@HIDDEN>
<b6348225-e69e-4432-8155-801dfcd1e933@HIDDEN>
<86plt7dyvu.fsf@HIDDEN>
<963412d9-85b9-4afe-a29f-52981f24aa5b@HIDDEN>
<86zfsaaqm1.fsf@HIDDEN>
<431cc3a7-141e-414f-8650-72771609c407@HIDDEN>
<86ed9jhkox.fsf@HIDDEN>
<becd5819-6b15-422a-ba4f-106c03a04bbd@HIDDEN>
Date: Fri, 31 May 2024 09:18:49 +0300
Message-ID: <86frty34km.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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 (-)
> And it will set up the '...-previous-window' variable
Not a variable, but a window parameter. A buffer-local variable
can't be used because for example 'vc-diff-internal' uses such
call sequence:
(set-buffer buffer)
(pop-to-buffer (current-buffer))
so 'display-buffer' is called from 'pop-to-buffer' in the wrong buffer.
Therefore, when using a window parameter, the solution is very simple
like in the following patch that allows a short customization:
(setq display-buffer-base-action
'(nil (set-previous-window . t)))
Then users can use anything such as 'C-x 4 1' or 'C-x 4 4',
and after this the subsequent navigation will reuse
the same window.
Even 'next-error-no-select' ('n' and 'p' keys in the grep buffer)
that hard-codes 'inhibit-same-window', still uses the mru window,
because it's 'second-best-window'.
diff --git a/lisp/window.el b/lisp/window.el
index b014be6a7cf..ff12a2225b5 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -7883,7 +7888,8 @@ display-buffer
specified by the ACTION argument."
(interactive (list (read-buffer "Display buffer: " (other-buffer))
(if current-prefix-arg t)))
- (let ((buffer (if (bufferp buffer-or-name)
+ (let ((old-selected-window (selected-window))
+ (buffer (if (bufferp buffer-or-name)
buffer-or-name
(get-buffer buffer-or-name)))
(buf-name (if (bufferp buffer-or-name)
@@ -7933,6 +7938,8 @@ display-buffer
(select-window old-selected-window)))
(remove-hook 'post-command-hook postfun))))
(add-hook 'post-command-hook postfun)))
+ (when (cdr (assq 'set-previous-window alist))
+ (set-window-parameter old-selected-window 'previous-window window))
(and (windowp window) window))))
(defun display-buffer-other-frame (buffer)
@@ -8638,6 +8645,7 @@ display-buffer-in-previous-window
(display-buffer-reuse-frames 0)
(t (last-nonminibuffer-frame))))
(previous-window (cdr (assq 'previous-window alist)))
+ (set-previous-window (cdr (assq 'set-previous-window alist)))
best-window second-best-window window)
;; Scan windows whether they have shown the buffer recently.
(catch 'best
@@ -8654,6 +8662,9 @@ display-buffer-in-previous-window
(when (and previous-window (symbolp previous-window)
(boundp previous-window))
(setq previous-window (symbol-value previous-window)))
+ (when-let ((set-previous-window)
+ (prev (window-parameter (selected-window) 'previous-window)))
+ (setq previous-window prev))
(when (and (setq window previous-window)
(window-live-p window)
(or (eq buffer (window-buffer window))
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.Received: (at 70949) by debbugs.gnu.org; 30 May 2024 08:54:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 30 04:54:55 2024 Received: from localhost ([127.0.0.1]:53445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sCbYl-0008FC-Ht for submit <at> debbugs.gnu.org; Thu, 30 May 2024 04:54:55 -0400 Received: from mout.gmx.net ([212.227.17.21]:56367) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rudalics@HIDDEN>) id 1sCbYj-0008En-Jg for 70949 <at> debbugs.gnu.org; Thu, 30 May 2024 04:54:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1717059277; x=1717664077; i=rudalics@HIDDEN; bh=0NkHi+JTRLw8tNPYEm5YK7/Oym/ycKVnyoxbYRrj2jE=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=adcHzCWWoU6WgCKcuxieTHRNFJFP0KDXvPciRdMWfMZh3lZosuSkoLyGFQ/2jU8q oTIDg5Vio0RQW3JmAWGy2WNVDHLbGEBAGvWABDFajZh9tN+OjjYnWxvNZhfekXtdf jqaeIypS+Fj7FrrQ6Z+eiwf5dSIZdgGA3Na3YIylMBrHLV/8YRaCCblgM7lk55rjD /9TSL4vWwF0rh/zFznsCrqV3dcaZghpWnbKb+TSaTHSQpBHLBqp6Elv2Xlz/33VpY 796hDIDYCoaHmoO9zGBa9ATefGr+NrbpzsJRMGMGTDTIUYxSkx94i0+KoA9VPJzmu iPGNEO3eGuNHp+vCEQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.31.113] ([46.125.249.43]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MowGU-1spis63Zok-00nNYn; Thu, 30 May 2024 10:54:36 +0200 Message-ID: <becd5819-6b15-422a-ba4f-106c03a04bbd@HIDDEN> Date: Thu, 30 May 2024 10:54:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#70949: display-buffer-choose-some-window To: Juri Linkov <juri@HIDDEN> References: <86jzjwqqmd.fsf@HIDDEN> <86r0e32fnj.fsf@HIDDEN> <f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN> <867cft0xt2.fsf@HIDDEN> <ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN> <86ed9xvz3o.fsf@HIDDEN> <73251208-1e4c-4231-ae58-faf82363f241@HIDDEN> <86jzjoo23l.fsf@HIDDEN> <9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN> <86cypfm6s7.fsf@HIDDEN> <d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN> <86o78xm9y5.fsf@HIDDEN> <78dfee56-80b4-4ba7-a012-df31abd21743@HIDDEN> <86sey8jv66.fsf@HIDDEN> <f9970431-325e-44b0-b959-ed9839d7ba47@HIDDEN> <86zfsfqgtl.fsf@HIDDEN> <b6348225-e69e-4432-8155-801dfcd1e933@HIDDEN> <86plt7dyvu.fsf@HIDDEN> <963412d9-85b9-4afe-a29f-52981f24aa5b@HIDDEN> <86zfsaaqm1.fsf@HIDDEN> <431cc3a7-141e-414f-8650-72771609c407@HIDDEN> <86ed9jhkox.fsf@HIDDEN> Content-Language: en-US From: martin rudalics <rudalics@HIDDEN> In-Reply-To: <86ed9jhkox.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:dUumML+/atIJ1DNauB8HBhanYBUV4At8h8NEg/x9S9rRZPsOfYH SNHSraGIq/OMVVdWJHabq2z3FUbSIf5Osa35ix84quPcvGmkK3MpB/fG8sgR4vw8pQV/nJk NKtpPnSKPsKe+Awxw7Z0FJp9UsFj2mkBG7PHFKSmKx2nRRt1qA95a7yC46+J11skU6fFua+ vopZ9Z5UjzE30kfQfky0g== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:w66B9D8/T1o=;uiOtLgwQhI1KQfGYJfhqJdc9hvC wGZqVvtHc7OIH27Ggb2jqZayqQxgVLC/NQQ0ZEjElD+kNRkeED3Y4GoARce+++hMCpJq/FKKJ I8aOoNUh+tEhHHaXm9ja3od5b397rWlFosIIE67fPnxDfHQ10KplTKquiDCbHxd7LqLgBLfeB nLzI+RhP4XwK3kRcLN/VmVIwW28yaMGgdiay14CoxSRR+ZE5qVNYRQuXL5+iBagqT3taloq+x xpqKD1mnSlAbWGWHaoZ1+8lc7b4nNSQ78lJCmu0Y7Tf2vVqC2a//BGEI5i2hSNNT51S67J+u/ wVhIkX/tHNQaQouWzVMIfh4TY85yiewEFGUzna3GfW482WOypApKe6dbIz+6v59gBvvOOZvQL kf/zfhSuZfkEIXPN6XLc87YTL7aaxCuGtHuaTfD+KOMpQ+51tq2SKSHY0mLuQYY25YAZ+wR63 HaUIuvJgLhYKM0PLa1b0u5A876nPnZ6eEIIa1rcAx73iogaigmdkLhu7/7d81l9hL4pvqHbo7 mpKMyGow7ptKVHVjBu4+z+DPvqTmeCBNj/O3lb5y3Nnv2ulbtOT9AIJCsrtVUPWdItc9AOn0W Q37rjBn0fcjgT8vmCW6035G2Iin5OfWbINpFHuKtehSVPkVyJfVc4IylyC3cYRna9Sw70bp9o +XrFh11JnGY9oNwAnsttICBhsjhwu8euPsI3cuo75pNfWsrNuTSUTWa2h2BGqp/UmJR3Fwpbj Oi8zKFqU/LhS7qEmYQXQn+lq4n3FYWUE2tlMz57n+B3H6aWaRHVBOwhU1CXkUlgNjoNdKSx+d 1Ubb5VldMAd4rlVxanycCFU17d0NqZQIk2O0iIfxem4DA= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 70949 Cc: 70949 <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 (-) > Sorry, I don't understand why the design should be limited to > compile-goto-error/next-error only. That's what I keep saying here all the time. > As a unified framework we could provide a new defcustom with a list > of categories for which display-buffer will set a buffer-local variable > or the window parameter 'previous-window', then the next invocations > of the same command will reuse it. I don't think that one defcustom will do. And if we try building on what 'next-error' finds for us, buffer-local variables won't help either. The common underlying principle is that a user starts an operation to display several file-visiting buffers in a row triggered by some sort of operation on these files like a compilation, grep, or version control action. That action usually produces a buffer I call "results buffer" and sequentially scanning that buffer will produce "file buffers" that should be handled in a specific way. So we need: - A method for extracting a list of file names from the results buffer (not needed if the results buffer contains them already but in my experience these file names are often relative only). Obviously, this is already done for each of the contexts we want to address but it would be nice to have some unified approach here: A list of absolute file names and a pointer to which is the one to be displayed next. - A method for displaying the first file buffer. It will decide whether the file buffer replaces the results buffer in its window, uses some other window on the same frame or even another frame... And it will set up the '...-previous-window' variable specifying the window that should be used for displaying the remaining file buffers. - Key-bindings for displaying the next and previous file buffers from _any_ window selected. Ideally, these would be M-n and M-p. - A method for quitting. Deleting the file buffer window (or frame) is one way to do that. Invoking M-n with the last file buffer current could be another way - possibly after a 'quit' prompt. Otherwise, 'quit-window' and the 'quit-restore' parameter should handle that, where the latter would have to be set up when displaying the first file buffer. The major customizable thing I see here is the method for displaying the first file buffer and I think that that should be done for each type of results buffer separately. martin
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.Received: (at 70949) by debbugs.gnu.org; 30 May 2024 06:37:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 30 02:37:00 2024 Received: from localhost ([127.0.0.1]:48590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sCZPH-00061z-W7 for submit <at> debbugs.gnu.org; Thu, 30 May 2024 02:37:00 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:45619) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1sCZPG-00061g-6W for 70949 <at> debbugs.gnu.org; Thu, 30 May 2024 02:36:58 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id E9D0DE0004; Thu, 30 May 2024 06:36:20 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#70949: display-buffer-choose-some-window In-Reply-To: <431cc3a7-141e-414f-8650-72771609c407@HIDDEN> (martin rudalics's message of "Wed, 29 May 2024 10:49:37 +0200") Organization: LINKOV.NET References: <86jzjwqqmd.fsf@HIDDEN> <86r0e32fnj.fsf@HIDDEN> <f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN> <867cft0xt2.fsf@HIDDEN> <ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN> <86ed9xvz3o.fsf@HIDDEN> <73251208-1e4c-4231-ae58-faf82363f241@HIDDEN> <86jzjoo23l.fsf@HIDDEN> <9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN> <86cypfm6s7.fsf@HIDDEN> <d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN> <86o78xm9y5.fsf@HIDDEN> <78dfee56-80b4-4ba7-a012-df31abd21743@HIDDEN> <86sey8jv66.fsf@HIDDEN> <f9970431-325e-44b0-b959-ed9839d7ba47@HIDDEN> <86zfsfqgtl.fsf@HIDDEN> <b6348225-e69e-4432-8155-801dfcd1e933@HIDDEN> <86plt7dyvu.fsf@HIDDEN> <963412d9-85b9-4afe-a29f-52981f24aa5b@HIDDEN> <86zfsaaqm1.fsf@HIDDEN> <431cc3a7-141e-414f-8650-72771609c407@HIDDEN> Date: Thu, 30 May 2024 09:34:38 +0300 Message-ID: <86ed9jhkox.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 70949 Cc: 70949 <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 (-) > We are talking about displaying, in one and the same window, buffers > whose only relationship is that they appear in the results list of > compilation or grep output. That's why I think that a buffer-local > variable doesn't make sense here. It works for 'compile-goto-error' but > only if, as a user, you invoke 'display-buffer' from the results window. > If you are in the file window and want to display the next file, you > have to go back to the results window. If you use one window to show > results and files, you have to redisplay the results in that window > first. All this is tedious, especially given the fact that 'next-error' > already can guess from where to get the name of the next file to show. > > I think we need a unified framework that supports 'compile-goto-error' > and 'next-error' out of the box, where the later command can be invoked > from anywhere (although the key-binding in the results buffer is > obscured by 'compilation-next-error'). Which means that we should use a > global variable, say 'compilation-previous-window', that these commands > use to show the next file buffer. > > This variable should be set up by the first invocation of either > 'compile-goto-error' or 'next-error' and should be reset by > 'quit-window' and 'delete-window'. In addition, we'd need > 'grep-previous-window' and 'occur-previous-window' variables and > whatever else falls into this category. > > 'next-error' could first determine, as it does now, to which category > the user request belongs. If it's the compilation category, it consults > 'compilation-previous-window' and, if that's a live window, calls > 'display-buffer' with a 'display-buffer-in-previous-window' action and > 'compilation-previous-window' as 'previous-window' action alist entry. > If it's not a live window, it has to first find or make a suitable > window, set 'compilation-previous-window' to that window and maybe mark > the window as softly dedicated so it won't get used too soon by other > 'display-buffer' calls. > > Whether all this should be done by 'next-error' or within > 'display-buffer' is to decide. In the latter case, 'next-error' could > pass to 'display-buffer' a 'previous-window' entry whose value is > something like the symbol 'compilation-previous-window' and > 'display-buffer' would have to do the work I sketched above. This has > the advantage that 'compile-goto-error' could use the same underlying > mechanism and no code would be duplicated. The disadvantage is that > people who know about the inner working of compilation buffers and > 'next-error' would have to work within window.el. Sorry, I don't understand why the design should be limited to compile-goto-error/next-error only. I have the same problem with many other commands. For example, vc-diff from such buffers as *vc-dir*, *vc-change-log* opens the diff buffer in unpredictable windows, every time choosing another window that makes the window management unusable (need to quit the buffer displayed in the wrong window and re-run the diff command again). As a unified framework we could provide a new defcustom with a list of categories for which display-buffer will set a buffer-local variable or the window parameter 'previous-window', then the next invocations of the same command will reuse it.
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.Received: (at 70949) by debbugs.gnu.org; 29 May 2024 08:49:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 29 04:49:58 2024 Received: from localhost ([127.0.0.1]:52406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sCF0P-00044Z-SA for submit <at> debbugs.gnu.org; Wed, 29 May 2024 04:49:58 -0400 Received: from mout.gmx.net ([212.227.15.18]:35751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rudalics@HIDDEN>) id 1sCF0N-00044H-5S for 70949 <at> debbugs.gnu.org; Wed, 29 May 2024 04:49:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1716972578; x=1717577378; i=rudalics@HIDDEN; bh=JqhuNTfKoD1jNs50kWpAjmH1WbJuSxvuw1SX6YrzB94=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=mHHI2NevMAS/3ROP6eNNlNQW21/gTnWtjRK0z+q+UTJizmoiVIL3wYMeCC9d+nUW GuU4SL90FDwQ/Wcz+iZaYqbLZdfX/TM3u2oGQkUKwOoMBLrxTsKNWZfwauzRQ3sUF PrYYMPGX+PU/jnJ581iz2Aj+hz0wU2leEvFXEUEwDMK8EvLYxNL7sbSytYMvb/OVM 1592joSTVPSV36N5WQ1hgEqDQFHTULwuyRmoJW0iwaXQl7Y6yUgFMnkV+k4y3L5sV bj2wd/CqvP5WDjJb+mCK56bBiI4iiOXeCaSYISJ85xRlKa6fQiVqhMl4Ar55Xk6WU QWdIMWywIkbMm/PITg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.31.113] ([46.125.249.84]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mk0JW-1swG3W1IpE-00jN04; Wed, 29 May 2024 10:49:38 +0200 Message-ID: <431cc3a7-141e-414f-8650-72771609c407@HIDDEN> Date: Wed, 29 May 2024 10:49:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#70949: display-buffer-choose-some-window To: Juri Linkov <juri@HIDDEN> References: <86jzjwqqmd.fsf@HIDDEN> <8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN> <86r0e32fnj.fsf@HIDDEN> <f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN> <867cft0xt2.fsf@HIDDEN> <ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN> <86ed9xvz3o.fsf@HIDDEN> <73251208-1e4c-4231-ae58-faf82363f241@HIDDEN> <86jzjoo23l.fsf@HIDDEN> <9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN> <86cypfm6s7.fsf@HIDDEN> <d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN> <86o78xm9y5.fsf@HIDDEN> <78dfee56-80b4-4ba7-a012-df31abd21743@HIDDEN> <86sey8jv66.fsf@HIDDEN> <f9970431-325e-44b0-b959-ed9839d7ba47@HIDDEN> <86zfsfqgtl.fsf@HIDDEN> <b6348225-e69e-4432-8155-801dfcd1e933@HIDDEN> <86plt7dyvu.fsf@HIDDEN> <963412d9-85b9-4afe-a29f-52981f24aa5b@HIDDEN> <86zfsaaqm1.fsf@HIDDEN> Content-Language: en-US From: martin rudalics <rudalics@HIDDEN> In-Reply-To: <86zfsaaqm1.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:YKJUyKNStBDUukRtApMeLaJ4npSXI+fKSYF+cKvza4QYTBrtARn Gskcd1OPjghCA0+vCobwFIHZym1hUrdTLMRVyspVaYoT4SKXIP5AxMzostIsq5zJ2VF1L47 3iRGZU4jM82vDfamIv7Hty82iIDWrYSwNDLyKTrR5p77jdFq+Jl2t5BFr9hbrwc18bZ16Ar /YxoURX1/FB3/UsDZZhcA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:j6RzUgfUqYg=;6QPLtXORalHHMGoj9B8qIeqhfvm qyJUYG2INx0zuCAVJENiVaNeMWiHpHJvbddpUe4hNLcYHXZaLYiIYaPxgiISRnXphsN4bP6t8 Pqz5fNHtmL/hEzRDvkZDlD3aoEmSx53VTFPV8+GZFVdNDX1GWuoa+X5G0HX+dTVgsPPkNdrW+ qh79zah1loJaHaeOLaekeDv+/FNjfFIAVd9vdq4zerKYqnmRAGUi1P6sy5vc+chiG1li9TbLb kyqzjvz0XZ5GWu+kVg3AT0H8UfxXwLndfDRqo+eMxeGOS9nFMXGDxzUiRNCBgpoLzmcJ6kpSE xhy3EX9jNUwlsQuX0WAsQzzc4ewIP6d51dCSJbd+4tor8gKf90Co/U0M7vVMxTSzdihxp8uo8 iNoVO1ThXJNG3HGQb/NGG4ALi0qj5VdFjoMGl5/+Z1TkMGAEdSKM+OlxuuLyTZPWH5//A8Wda q7nFPo1YR/oa1g89PrHnaE6zggw5nNr41T1GUUo8m4iehwgX47mE+sCceikM3DLRehR0YLM0Y 2wf8GOcinC+eRN2nvnJtuJqAqz0qMe3dAHRENHke+rAHRIeUcDpnV0+BmVW/OLkfMt0A0hiS1 aaSDUZmaIK3qjkwzKWqk9fQZEV8aZI8Popbb52YgJh063r8kJmtcyRfamGnkYjMtMskNmWaF1 X+I8/f89ibxoIOH2ATCSaXKoYuc1TVvTxztfxLXuOniHnUusXvl8dsT0Oys9APnDknn3om81F UU2yNZ4n/+Qz7SOiUOFtaf2etLHJUnD/C2Yx94u4dL7jvMYsIfqW1SgrROJbk1FrW718ZuaKu icbWxRLFEJSMNJUjVrJL8/OIWrOFNenxt0yy5gIY7aMRo= X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 70949 Cc: 70949 <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: -0.2 (/) > This is exactly what I already use in ~/.emacs, and it works nicely. > Any chance to add something like this optionally to window.el? > > (defvar-local display-buffer-previous-window nil) > > (add-to-list 'display-buffer-alist > '((category . compilation) > display-buffer-in-previous-window > (previous-window . display-buffer-previous-window))) > > (define-advice compile-goto-error (:around (ofun &rest args) previous-window) > (let ((buffer (current-buffer))) > (apply ofun args) > (with-current-buffer buffer > (setq-local display-buffer-previous-window (selected-window))))) > > The main problem is where to set this buffer-local variable > (I think better to use the buffer-local variable instead > of the window parameter since visiting results from rgrep > is a property of the buffer, not the window). > Instead of the advice like above, 'display-buffer-previous-window' > should be set in every buffer displayed by 'display-buffer'. > Isn't setting this variable in all buffers too excessive? > But I see no other way because the user might want to > force displaying the results in the same rgrep window, then > display-buffer-in-previous-window should reuse the same window. We are talking about displaying, in one and the same window, buffers whose only relationship is that they appear in the results list of compilation or grep output. That's why I think that a buffer-local variable doesn't make sense here. It works for 'compile-goto-error' but only if, as a user, you invoke 'display-buffer' from the results window. If you are in the file window and want to display the next file, you have to go back to the results window. If you use one window to show results and files, you have to redisplay the results in that window first. All this is tedious, especially given the fact that 'next-error' already can guess from where to get the name of the next file to show. I think we need a unified framework that supports 'compile-goto-error' and 'next-error' out of the box, where the later command can be invoked from anywhere (although the key-binding in the results buffer is obscured by 'compilation-next-error'). Which means that we should use a global variable, say 'compilation-previous-window', that these commands use to show the next file buffer. This variable should be set up by the first invocation of either 'compile-goto-error' or 'next-error' and should be reset by 'quit-window' and 'delete-window'. In addition, we'd need 'grep-previous-window' and 'occur-previous-window' variables and whatever else falls into this category. 'next-error' could first determine, as it does now, to which category the user request belongs. If it's the compilation category, it consults 'compilation-previous-window' and, if that's a live window, calls 'display-buffer' with a 'display-buffer-in-previous-window' action and 'compilation-previous-window' as 'previous-window' action alist entry. If it's not a live window, it has to first find or make a suitable window, set 'compilation-previous-window' to that window and maybe mark the window as softly dedicated so it won't get used too soon by other 'display-buffer' calls. Whether all this should be done by 'next-error' or within 'display-buffer' is to decide. In the latter case, 'next-error' could pass to 'display-buffer' a 'previous-window' entry whose value is something like the symbol 'compilation-previous-window' and 'display-buffer' would have to do the work I sketched above. This has the advantage that 'compile-goto-error' could use the same underlying mechanism and no code would be duplicated. The disadvantage is that people who know about the inner working of compilation buffers and 'next-error' would have to work within window.el. martin
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 28 May 2024 16:32:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 28 12:32:17 2024
Received: from localhost ([127.0.0.1]:46855 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sBzkG-0006Iw-Lo
for submit <at> debbugs.gnu.org; Tue, 28 May 2024 12:32:16 -0400
Received: from relay5-d.mail.gandi.net ([217.70.183.197]:57245)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1sBzkF-0006If-RC
for 70949 <at> debbugs.gnu.org; Tue, 28 May 2024 12:32:16 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 6287E1C0007;
Tue, 28 May 2024 16:31:39 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#70949: display-buffer-choose-some-window
In-Reply-To: <963412d9-85b9-4afe-a29f-52981f24aa5b@HIDDEN> (martin rudalics's
message of "Tue, 28 May 2024 10:05:41 +0200")
Organization: LINKOV.NET
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
<86r0e32fnj.fsf@HIDDEN>
<f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN>
<867cft0xt2.fsf@HIDDEN>
<ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN>
<86ed9xvz3o.fsf@HIDDEN>
<73251208-1e4c-4231-ae58-faf82363f241@HIDDEN>
<86jzjoo23l.fsf@HIDDEN>
<9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN>
<86cypfm6s7.fsf@HIDDEN>
<d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN>
<86o78xm9y5.fsf@HIDDEN>
<78dfee56-80b4-4ba7-a012-df31abd21743@HIDDEN>
<86sey8jv66.fsf@HIDDEN>
<f9970431-325e-44b0-b959-ed9839d7ba47@HIDDEN>
<86zfsfqgtl.fsf@HIDDEN>
<b6348225-e69e-4432-8155-801dfcd1e933@HIDDEN>
<86plt7dyvu.fsf@HIDDEN>
<963412d9-85b9-4afe-a29f-52981f24aa5b@HIDDEN>
Date: Tue, 28 May 2024 19:19:06 +0300
Message-ID: <86zfsaaqm1.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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 (-)
>> Currently the main question is where to add display-buffer-in-related-window?
>> It should be added to display-buffer-fallback-action between
>> display-buffer-in-previous-window and display-buffer-use-some-window?
>> If not, then users should add it by customizing display-buffer-base-action?
>
> Hopefully it can be merged into 'display-buffer-in-previous-window'.
This is exactly what I already use in ~/.emacs, and it works nicely.
Any chance to add something like this optionally to window.el?
(defvar-local display-buffer-previous-window nil)
(add-to-list 'display-buffer-alist
'((category . compilation)
display-buffer-in-previous-window
(previous-window . display-buffer-previous-window)))
(define-advice compile-goto-error (:around (ofun &rest args) previous-window)
(let ((buffer (current-buffer)))
(apply ofun args)
(with-current-buffer buffer
(setq-local display-buffer-previous-window (selected-window)))))
The main problem is where to set this buffer-local variable
(I think better to use the buffer-local variable instead
of the window parameter since visiting results from rgrep
is a property of the buffer, not the window).
Instead of the advice like above, 'display-buffer-previous-window'
should be set in every buffer displayed by 'display-buffer'.
Isn't setting this variable in all buffers too excessive?
But I see no other way because the user might want to
force displaying the results in the same rgrep window, then
display-buffer-in-previous-window should reuse the same window.
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 28 May 2024 08:06:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 28 04:06:00 2024
Received: from localhost ([127.0.0.1]:45625 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sBrqJ-0003yU-Pr
for submit <at> debbugs.gnu.org; Tue, 28 May 2024 04:06:00 -0400
Received: from mout.gmx.net ([212.227.17.21]:32791)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1sBrqI-0003yI-Bt
for 70949 <at> debbugs.gnu.org; Tue, 28 May 2024 04:05:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1716883542; x=1717488342; i=rudalics@HIDDEN;
bh=NH0pdDh2Fw9j1/X8R0+ZzMNI+/V48uQY0RntJgp9TJ8=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc:
References:From:In-Reply-To:Content-Type:
Content-Transfer-Encoding:cc:content-transfer-encoding:
content-type:date:from:message-id:mime-version:reply-to:subject:
to;
b=IMmRoI9TdvnQKWQhRLwTntCtbniEMLEPfDZyajWMCBZT9aLLvMDSWKbI5PS0QzlH
KDOzITznf1TqQ/hLSa9V0oJRxSWPiTxTeXqDbZ8nM1aL3/MzkNItj+DceBq3i9jeL
elvTR/XTrhRql9EsElzsYJgb9EZ7RmkCrKIHOe/Bd9AvcKJcepBMxse2t98Un1sDg
KNc1M977oMnY6tOZPmmSzV9DZMkjFlnFtKoKwLBNIPT3xKms1YJroAN+npprYUbU4
eM+0SPYz6nVVuUhkR033T1tv++chfI7bpzt+iHqVQ984P9iAjUVM1JMbRaeEChocS
rvYknH1HNE+g8WCJ2w==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([213.142.97.114]) by mail.gmx.net (mrgmx104
[212.227.17.168]) with ESMTPSA (Nemesis) id 1MGhuU-1sGpvA2Ajq-00HM9l; Tue, 28
May 2024 10:05:42 +0200
Message-ID: <963412d9-85b9-4afe-a29f-52981f24aa5b@HIDDEN>
Date: Tue, 28 May 2024 10:05:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#70949: display-buffer-choose-some-window
To: Juri Linkov <juri@HIDDEN>
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
<86r0e32fnj.fsf@HIDDEN>
<f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN>
<867cft0xt2.fsf@HIDDEN>
<ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN>
<86ed9xvz3o.fsf@HIDDEN>
<73251208-1e4c-4231-ae58-faf82363f241@HIDDEN>
<86jzjoo23l.fsf@HIDDEN>
<9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN>
<86cypfm6s7.fsf@HIDDEN>
<d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN>
<86o78xm9y5.fsf@HIDDEN>
<78dfee56-80b4-4ba7-a012-df31abd21743@HIDDEN>
<86sey8jv66.fsf@HIDDEN>
<f9970431-325e-44b0-b959-ed9839d7ba47@HIDDEN>
<86zfsfqgtl.fsf@HIDDEN>
<b6348225-e69e-4432-8155-801dfcd1e933@HIDDEN>
<86plt7dyvu.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86plt7dyvu.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:z79vKSgKWvw0W0VdzcLYHBL7xKzja4E6jTqWVozprR/Wa54OZoy
KvAfYkCydcgA91RFAsDQ80AM4hXZXrmxxyVCCnKoWfcsb9o9YXM3nQaafRKQvyTTh5JDyVr
sAcCtkmeND1F3BzVmRT53h8iijXbjtt/DPurDzB9oIbCH3191OxN2K73/MATvhwh5j6+4Nh
0MC/zmJ5NUBn645WjbwlQ==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:5imLF4coiJg=;16vof5SPiNS/wTJyCnXa/ZAOlwA
T+/W6Y1Og8hldL2ec8EIXJP0QQfybqtBl9ohQ1ehjNp7eyX/KPuk2LdTg+HBidhKoSUn9gQHu
v1ypaubSv3/zB4SeswrMbB9bx6URJa6RutMujAT2uTvFvsJq2HsQ+ZtP1Um83h+PQ9XXhW4V+
FkHm58iBz7k46QRxyo6SJ3ikgWhjZVPJuBKk3RmAT+eQmo5g/1LQ+EP+S9/DrMTOQu/6otJcb
BM/oo/FOuXAt0p0eRVebzNxTqKG3hgoj1fukfmeAEQ8WXvW7qgdpAfrHKWKEZL0IbOxouNICZ
GMuk3n5inJRztFz2SyM6vPy8JWg2bOFcyQNiaImL/lsT2pdTiiuspJiKcThfGrhoDdf1VgsnK
xPmru4FD22YC8pSVlnDUcRLvIplKX/S/lKGj5brmt7l3WvItTOsSE9leOE9V3XM/FpxZzQ2Fa
yDLi3KnjMvp4orKA9fZkyl0Tt1OgxQBT+6v2ewLNc0tRGGuZNn5xaK1CjHOCVROWDuAaV0fEi
T1wcVyS8bVTsRpuSS/DgMIItHFksEeYirqSIGxOcsEFT5XLkVgUZRWUhEo9uwHuyiQME5Cm/W
sV+DXOfW7vmNFLTn2z4FVK9icNjGt8Z2QU8QoHqKlmEv8CP5NldZvxm79D7EjXCurMQFyZFFp
oEnWThKWOfT25bzSUhiIlTpF1I6XuWcuVHSyGGlvCGqUhykx8PQA3AtAdFWH3bBtLBBV4L4XE
dgW9aG2ptmJQntLtBzjUa7KSpTFJO5I/uTeSDrdowVOPev0sU1QjdIDDlAiZabfQVPfa+JlVG
Ccfc6gmBOfSd37r9YRo5Io7hh6pUxi4TQBxGy903QWcZ4=
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: >> Who would switch to the window? The user or
'display-buffer'
itself? > > The user. Tedious to explain and not really practicable. > I
don't understand why 'compilation-next-error' does not display > the source
buffer? Content analysis details: (2.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.0 SPF_PASS SPF: sender matches SPF record
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[213.142.97.114 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.21 listed in wl.mailspike.net]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.21 listed in list.dnswl.org]
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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: >> Who would switch to the window? The user or 'display-buffer'
itself? > > The user. Tedious to explain and not really practicable. > I
don't understand why 'compilation-next-error' does not display > the source
buffer?
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.21 listed in wl.mailspike.net]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[213.142.97.114 listed in zen.spamhaus.org]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.21 listed in list.dnswl.org]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.0 SPF_PASS SPF: sender matches SPF record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
>> Who would switch to the window? The user or 'display-buffer' itself?
>
> The user.
Tedious to explain and not really practicable.
> I don't understand why 'compilation-next-error' does not display
> the source buffer?
Historical reasons, I suppose.
> Currently the main question is where to add display-buffer-in-related-window?
> It should be added to display-buffer-fallback-action between
> display-buffer-in-previous-window and display-buffer-use-some-window?
> If not, then users should add it by customizing display-buffer-base-action?
Hopefully it can be merged into 'display-buffer-in-previous-window'.
Some random thoughts:
I suppose that 'next-error-find-buffer' should determine the "does the
selected window show the next-/previous-error capable buffer" predicate
and, together with some option, set up either the one window fits all
strategy (whether a file buffer should be shown in the results window)
or a multiple windows strategy. Always considering the possibility that
the results buffer is nowhere shown initially.
If 'next-error-find-buffer' finds a buffer other than
'next-error-last-buffer', it should probably tell 'display-buffer' that
we apparently start a new series of results, that we shall push the last
buffer somehow, start the new series of results, and pop to that last
buffer when quitting the new series. 'display-buffer' should then reuse
the "same" window in the one-window case or the file window in the
multiple windows case to continue with the previous series of results.
Whether and how to handle the case where two series of results should be
displayed in some intertwined fashion is another question.
One thing we should consider carefully is how to side-step the special
case that one of the file buffers is already shown in some other window
and how to either avoid showing the same buffer twice or rather show it
twice when the next error location is not shown in that other window.
martin
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.Received: (at 70949) by debbugs.gnu.org; 27 May 2024 18:00:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 27 14:00:02 2024 Received: from localhost ([127.0.0.1]:45213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sBedd-00006q-Ei for submit <at> debbugs.gnu.org; Mon, 27 May 2024 14:00:02 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:38077) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1sBedb-00006d-Kh for 70949 <at> debbugs.gnu.org; Mon, 27 May 2024 14:00:00 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id DEA051BF204; Mon, 27 May 2024 17:59:43 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#70949: display-buffer-choose-some-window In-Reply-To: <b6348225-e69e-4432-8155-801dfcd1e933@HIDDEN> (martin rudalics's message of "Sun, 26 May 2024 10:54:20 +0200") Organization: LINKOV.NET References: <86jzjwqqmd.fsf@HIDDEN> <8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN> <86r0e32fnj.fsf@HIDDEN> <f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN> <867cft0xt2.fsf@HIDDEN> <ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN> <86ed9xvz3o.fsf@HIDDEN> <73251208-1e4c-4231-ae58-faf82363f241@HIDDEN> <86jzjoo23l.fsf@HIDDEN> <9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN> <86cypfm6s7.fsf@HIDDEN> <d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN> <86o78xm9y5.fsf@HIDDEN> <78dfee56-80b4-4ba7-a012-df31abd21743@HIDDEN> <86sey8jv66.fsf@HIDDEN> <f9970431-325e-44b0-b959-ed9839d7ba47@HIDDEN> <86zfsfqgtl.fsf@HIDDEN> <b6348225-e69e-4432-8155-801dfcd1e933@HIDDEN> Date: Mon, 27 May 2024 20:52:53 +0300 Message-ID: <86plt7dyvu.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 70949 Cc: 70949 <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 (-) >> I meant switching to the window to instruct display-buffer what window >> to use as mru, then switch back to the rgrep window. > > Who would switch to the window? The user or 'display-buffer' itself? The user. >> We already have 'previous-window' that I'm using for a long time, >> and it works nicely with such configuration: >> >> (defvar-local display-buffer-previous-window nil) >> >> (defun display-buffer-from-grep-p (_buffer-name _action) >> (with-current-buffer (window-buffer) >> (and (memq this-command '(compile-goto-error)) >> (derived-mode-p '(compilation-mode))))) >> >> (add-to-list 'display-buffer-alist >> '(display-buffer-from-grep-p >> display-buffer-in-previous-window >> (previous-window . display-buffer-previous-window) >> (inhibit-same-window . nil)) >> ;; Append to not override display-buffer-same-window >> 'append) >> >> (define-advice compile-goto-error (:around (ofun &rest args) previous-window) >> (let ((buffer (current-buffer))) >> (apply ofun args) >> (with-current-buffer buffer >> (setq-local display-buffer-previous-window (selected-window))))) >> >> But this is very complicated configuration. So I wanted to help people >> to do basically the same with much simpler setting that overrides >> the hard-coded 'lru' with just '(some-window . mru)'. > > I think that's what we want here and it should cover all sorts of > 'next-error-function' too. But 'get-mru-window' won't cut it. I agree that 'get-mru-window' is too limited. >> The only problem with '(some-window . mru)' is that its NOT-SELECTED is t, >> so this excludes the very useful case of displaying the buffer >> in the same selected window. For example, with 'previous-window' >> I often visit rgrep results in the same window where the rgrep buffer >> was displayed. This keeps everything confined to one window. > > We could provide two basic modes: One mode where the compilation, grep, > or occur buffer is always kept visible and the file buffers are > displayed in one or a few other windows. And a mode where only one > window is used. > > In either case we could use a window parameter, say 'next-window', that > indicates that this window shall be used for the next 'display-buffer' > call with a non-nil 'next-window' alist entry. The value could be > 'grep', 'occur' 'compile' or whatever we want so a user could do, for > example, a grep within the outer context of analyzing compilation > output. Ok, I will throw out everything that I did, and will restart with your function display-buffer-in-related-window. > I see the following problems: > > - How to set up the 'next-window' parameter in the first call of a given > context. IIUC we don't have a unique starting function for > establishing a suitable context of a series of related calls. So > both, 'compile-goto-error' and 'next-error', would have to call > 'display-buffer' with an appropriate 'next-window' entry. For me, > it's been always confusing that 'compilation-next-error' does not > display the source buffer while 'next-error' does. I don't understand why 'compilation-next-error' does not display the source buffer? > - How to remove/reset the parameter after the last call. 'quit-window' > should probably do that, but I'm not sure. > > - How to "nest" contexts when windows are shared. If the same window > were used for displaying grep results within a compilation results > context, the 'next-window' parameter would have to become a list and > 'quit-window' should probably pop an entry from it. Nothing so complicated needed. I will just adapt your starting point with display-buffer-in-related-window to the useful configuration above. Currently the main question is where to add display-buffer-in-related-window? It should be added to display-buffer-fallback-action between display-buffer-in-previous-window and display-buffer-use-some-window? If not, then users should add it by customizing display-buffer-base-action?
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.Received: (at 70949) by debbugs.gnu.org; 26 May 2024 08:54:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 26 04:54:40 2024 Received: from localhost ([127.0.0.1]:38336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sB9eJ-0000LE-Nj for submit <at> debbugs.gnu.org; Sun, 26 May 2024 04:54:40 -0400 Received: from mout.gmx.net ([212.227.15.15]:33641) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rudalics@HIDDEN>) id 1sB9eG-0000Kx-FF for 70949 <at> debbugs.gnu.org; Sun, 26 May 2024 04:54:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1716713662; x=1717318462; i=rudalics@HIDDEN; bh=PhuupAr8RxeFqfoPR62jZRcQinENR9IIFrBoGX+ceBs=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=btuP2Sl/4rnwWgIbICxfijUGsZdTs9htqJ1e52ZjWBzfYwdDWALIR4zz7baRZVls rvHUvydBhg9oUWsutHb6xjyRWH/rsz1s+n/ufLZqGPUcPDu89Ubkbmll56wjHN/Gl jiqn/UHyI5RCeFSVecNHsJfHGMRrktZkx+W/AglKx4z18pzvwkr3njx+neoxoaVu3 77bU1Z0+bXFqnETYXbkN3D5TDyG0PmHgesk+5UyBvgZG9P5YU8RAGSHILMzd4+zlK CcRFXtrvxzQ66vY0daRgW+8A69C3e21ZWYoc6asg5RWf0C8cqqYAu5MzRTYUNQW8W l09m2jr9ohsL41yo3w== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.31.113] ([212.95.5.6]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MRCK6-1rqAsT3M0K-00OCoZ; Sun, 26 May 2024 10:54:21 +0200 Message-ID: <b6348225-e69e-4432-8155-801dfcd1e933@HIDDEN> Date: Sun, 26 May 2024 10:54:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#70949: display-buffer-choose-some-window To: Juri Linkov <juri@HIDDEN> References: <86jzjwqqmd.fsf@HIDDEN> <8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN> <86r0e32fnj.fsf@HIDDEN> <f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN> <867cft0xt2.fsf@HIDDEN> <ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN> <86ed9xvz3o.fsf@HIDDEN> <73251208-1e4c-4231-ae58-faf82363f241@HIDDEN> <86jzjoo23l.fsf@HIDDEN> <9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN> <86cypfm6s7.fsf@HIDDEN> <d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN> <86o78xm9y5.fsf@HIDDEN> <78dfee56-80b4-4ba7-a012-df31abd21743@HIDDEN> <86sey8jv66.fsf@HIDDEN> <f9970431-325e-44b0-b959-ed9839d7ba47@HIDDEN> <86zfsfqgtl.fsf@HIDDEN> Content-Language: en-US From: martin rudalics <rudalics@HIDDEN> In-Reply-To: <86zfsfqgtl.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:QeJYm57s9sm1u3xix9Uom17e4vmVK9Ja1MidvA8llZdpKBXsNuF GckCTFVIoq4+JZ8Fs3Gi7ejXQpp05GQapJCBfusUH1gvY7JlH9jX4eFxOX4Ls7SNxBO5Lvw FQYRusrwZNGi1x1xkxBbjGFolNV2KKoJHTiwRdpsHTBSl7i/6GVJpxGspukAEZXYwjP2w9a ao1Qo2N8wc3LRx27lQipg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:yFUaO6f3TyY=;Rxc2+wvb7ijbASH/UVn8rFSRyfZ rsz/HCUK7SJh6C2MgWxL7F8p/6/GGHozl0IWZSFhZD48I0YklaVtNAiYBTz3qaIoVBNOamm2o IOYOMK1tbRyguZqzEDoJGnDciJr2KqlpHgtYUqLA3fQgujViPayLklG4wM84k8FB1/iSeNjjH lOX2JpAhqyWZdOZS55Nko1CtYVEScvWWy7AVxQGxXvQp0nthcFCl0IzUEdUu2LYO1KF0TuWcf hfaDZCTX3+WxC7wsqvhn3dvItZXnOtc2gFHMNHK/gcOgIslGjQqgS9QFzRc+ZmPfDbjqGXRmf NxwuQy6LsxvOvgAJKzcRp5JTrE3kjIyTyVYULIT319VBP6UMK+kRzkYg04B+83zfPgQ2+To0A DR3J2oruVjOAEu+ocyfg2cFvJyLEo2T5xEOz8qjqYcOH29HgsDgstuY2E30ly4Z0Uc5208NoG 445xgqhb2aylhzjICr62RH7H14IktZSEiT7xkLWjzmG4hTYRL/egMdmgQNv+wbfdEqZolTAQx Ye1a9MFNcKaDt/BAlcPy8SPmX8DEwtzrBIFIwAPFnWCJkLsKJKFjX3cgCzICuWqVzlqG0V4qz ATsykat14v7uNW+nSR1oe+3pUhhVbGbfKVgGrMU6L5YXYtRnTl53xo60FUTBbwxdoYoqs1WxU +hBtoulOkYC25QncQjAkpAa7xcwuzLVSAs526nozTDufV8uARUY+iZfktdHwRQXorxTL8JuzN HPWY8j5Pwr18wZJCAA9Bp2x/RcKQOiBDcaVEex52fe4IFg7ubvaEEFfFs9jdSUtxQC8qkgo+C Eh6D9+DiH9WmWw2pE3YbRQlzJP/9hKSG2Rq9gzKWvcxkE= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 70949 Cc: 70949 <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 (-) > I meant switching to the window to instruct display-buffer what window > to use as mru, then switch back to the rgrep window. Who would switch to the window? The user or 'display-buffer' itself? > We already have 'previous-window' that I'm using for a long time, > and it works nicely with such configuration: > > (defvar-local display-buffer-previous-window nil) > > (defun display-buffer-from-grep-p (_buffer-name _action) > (with-current-buffer (window-buffer) > (and (memq this-command '(compile-goto-error)) > (derived-mode-p '(compilation-mode))))) > > (add-to-list 'display-buffer-alist > '(display-buffer-from-grep-p > display-buffer-in-previous-window > (previous-window . display-buffer-previous-window) > (inhibit-same-window . nil)) > ;; Append to not override display-buffer-same-window > 'append) > > (define-advice compile-goto-error (:around (ofun &rest args) previous-window) > (let ((buffer (current-buffer))) > (apply ofun args) > (with-current-buffer buffer > (setq-local display-buffer-previous-window (selected-window))))) > > But this is very complicated configuration. So I wanted to help people > to do basically the same with much simpler setting that overrides > the hard-coded 'lru' with just '(some-window . mru)'. I think that's what we want here and it should cover all sorts of 'next-error-function' too. But 'get-mru-window' won't cut it. > The only problem with '(some-window . mru)' is that its NOT-SELECTED is t, > so this excludes the very useful case of displaying the buffer > in the same selected window. For example, with 'previous-window' > I often visit rgrep results in the same window where the rgrep buffer > was displayed. This keeps everything confined to one window. We could provide two basic modes: One mode where the compilation, grep, or occur buffer is always kept visible and the file buffers are displayed in one or a few other windows. And a mode where only one window is used. In either case we could use a window parameter, say 'next-window', that indicates that this window shall be used for the next 'display-buffer' call with a non-nil 'next-window' alist entry. The value could be 'grep', 'occur' 'compile' or whatever we want so a user could do, for example, a grep within the outer context of analyzing compilation output. I see the following problems: - How to set up the 'next-window' parameter in the first call of a given context. IIUC we don't have a unique starting function for establishing a suitable context of a series of related calls. So both, 'compile-goto-error' and 'next-error', would have to call 'display-buffer' with an appropriate 'next-window' entry. For me, it's been always confusing that 'compilation-next-error' does not display the source buffer while 'next-error' does. - How to remove/reset the parameter after the last call. 'quit-window' should probably do that, but I'm not sure. - How to "nest" contexts when windows are shared. If the same window were used for displaying grep results within a compilation results context, the 'next-window' parameter would have to become a list and 'quit-window' should probably pop an entry from it. martin
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 24 May 2024 17:59:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 24 13:58:59 2024
Received: from localhost ([127.0.0.1]:38356 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sAZBz-0002CE-C8
for submit <at> debbugs.gnu.org; Fri, 24 May 2024 13:58:59 -0400
Received: from relay4-d.mail.gandi.net ([217.70.183.196]:47841)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1sAZBw-0002C5-MN
for 70949 <at> debbugs.gnu.org; Fri, 24 May 2024 13:58:57 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id B5E00E0002;
Fri, 24 May 2024 17:58:42 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#70949: display-buffer-choose-some-window
In-Reply-To: <f9970431-325e-44b0-b959-ed9839d7ba47@HIDDEN> (martin rudalics's
message of "Fri, 24 May 2024 11:32:16 +0200")
Organization: LINKOV.NET
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
<86r0e32fnj.fsf@HIDDEN>
<f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN>
<867cft0xt2.fsf@HIDDEN>
<ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN>
<86ed9xvz3o.fsf@HIDDEN>
<73251208-1e4c-4231-ae58-faf82363f241@HIDDEN>
<86jzjoo23l.fsf@HIDDEN>
<9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN>
<86cypfm6s7.fsf@HIDDEN>
<d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN>
<86o78xm9y5.fsf@HIDDEN>
<78dfee56-80b4-4ba7-a012-df31abd21743@HIDDEN>
<86sey8jv66.fsf@HIDDEN>
<f9970431-325e-44b0-b959-ed9839d7ba47@HIDDEN>
Date: Fri, 24 May 2024 20:38:34 +0300
Message-ID: <86zfsfqgtl.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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 (-)
>> This makes the behavior more predictable: the user will know that all
>> buffers will be displayed in the most recently used window, so the user
>> can switch to that window before continuing to navigate buffers.
>
> Not really. The window switched to becomes the selected window and the
> 'mru' window used will be the window where the user was working before
> the switch due to NOT-SELECTED being t.
I meant switching to the window to instruct display-buffer what window
to use as mru, then switch back to the rgrep window.
>>> Then maybe a separate category for rgrep buffers could help here.
>>
>> This is not about rgrep buffers.
>
> Consider the completely untested action function below supposed to be
> called with a (related-window . rgrep) alist argument.
We already have 'previous-window' that I'm using for a long time,
and it works nicely with such configuration:
(defvar-local display-buffer-previous-window nil)
(defun display-buffer-from-grep-p (_buffer-name _action)
(with-current-buffer (window-buffer)
(and (memq this-command '(compile-goto-error))
(derived-mode-p '(compilation-mode)))))
(add-to-list 'display-buffer-alist
'(display-buffer-from-grep-p
display-buffer-in-previous-window
(previous-window . display-buffer-previous-window)
(inhibit-same-window . nil))
;; Append to not override display-buffer-same-window
'append)
(define-advice compile-goto-error (:around (ofun &rest args) previous-window)
(let ((buffer (current-buffer)))
(apply ofun args)
(with-current-buffer buffer
(setq-local display-buffer-previous-window (selected-window)))))
But this is very complicated configuration. So I wanted to help people
to do basically the same with much simpler setting that overrides
the hard-coded 'lru' with just '(some-window . mru)'.
The only problem with '(some-window . mru)' is that its NOT-SELECTED is t,
so this excludes the very useful case of displaying the buffer
in the same selected window. For example, with 'previous-window'
I often visit rgrep results in the same window where the rgrep buffer
was displayed. This keeps everything confined to one window.
I see that in your display-buffer-in-related-window
'related-window' is a window parameter. I think this is
much better than a buffer-local variable that I used above.
But a new alist 'related-window' should also update
the 'related-window' window parameter in 'post-command-hook'
like 'post-command-select-window' does.
Then the customization for users would be very simple:
(add-to-list 'display-buffer-alist
'((category . rgrep) (display-buffer-in-related-window)))
Or maybe a better name would be 'display-buffer-in-last-window'?
In any case this looks like a workable solution
that will create a connection between windows.
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 24 May 2024 09:32:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 24 05:32:34 2024
Received: from localhost ([127.0.0.1]:36102 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sARHt-00063n-Nc
for submit <at> debbugs.gnu.org; Fri, 24 May 2024 05:32:34 -0400
Received: from mout.gmx.net ([212.227.17.22]:46453)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1sARHq-00063h-V0
for 70949 <at> debbugs.gnu.org; Fri, 24 May 2024 05:32:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1716543138; x=1717147938; i=rudalics@HIDDEN;
bh=PVAGNyvnINqwpoWnrLaHK6ObkyBvPYZxCP1tdvCSKBA=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc:
References:From:In-Reply-To:Content-Type:
Content-Transfer-Encoding:cc:content-transfer-encoding:
content-type:date:from:message-id:mime-version:reply-to:subject:
to;
b=MI9QjEf4AXmV9GyWjs8n4m9SmsvjY3jAx+qtzjorh7fIsvyvHpemwC92aRsCU7dM
a7tPZzVeeVAy8BSEoPMcW/oxOmdHoeH7M4dOn76827hQJ/GR09Zd6v3BwsfNwCApe
IYYebUTyZsPCPqyWhKUkwRR3GTsTOPBRst3ZqJzz9nnSdc/zHGDkda5SrwwC2pZX1
J56vCn3gQPbrhspt+f1g95YQYb4H7TJNzvt8E6j//NN2ezWgfwnDUh55wNHAelNI/
2RNTSyrFYCaeIB/n8TEa5ZVavveLgfB/HpzOT/S61SlTn1Q1dDF+Ir0mpmnGBEzFL
CG6vCn0qoUWRF88pqQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.146]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1Md6Mt-1skb7C39lL-00aBwi; Fri, 24
May 2024 11:32:17 +0200
Message-ID: <f9970431-325e-44b0-b959-ed9839d7ba47@HIDDEN>
Date: Fri, 24 May 2024 11:32:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#70949: display-buffer-choose-some-window
To: Juri Linkov <juri@HIDDEN>
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
<86r0e32fnj.fsf@HIDDEN>
<f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN>
<867cft0xt2.fsf@HIDDEN>
<ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN>
<86ed9xvz3o.fsf@HIDDEN>
<73251208-1e4c-4231-ae58-faf82363f241@HIDDEN>
<86jzjoo23l.fsf@HIDDEN>
<9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN>
<86cypfm6s7.fsf@HIDDEN>
<d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN>
<86o78xm9y5.fsf@HIDDEN>
<78dfee56-80b4-4ba7-a012-df31abd21743@HIDDEN>
<86sey8jv66.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86sey8jv66.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:t9mo7098rCb107aAv+C2ZmuEADiZqmN4pZ2Uki2WzkbCQvz3s83
7/MZkAviTEvkSUJXRCPSrmmCPP5FiCAQHXie2GAVJqpjAPt8qWcOkKbjKa/OPxfhev57KKi
ds3IB/kfl05Lpn+s2KUOEs/ucIQlku849xOzeCFa+Yn/kTPdJFtErOsale2GgSlTKGxUC2o
fRU/qLhd6VG9yQoETFMgA==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:R7g4dalobhE=;bKqM9nu2Ovlfva+w7m89e5lM5FL
C5/mwQJ6OcZ8EYP9XQfOjH5h9YjwOkdf3bk0lU8Hyk6x2ylw6oZl+rAR1JWpwc87+mvG1aNZa
rpOiUSznP04LteAmZPYc+3mq5/DeKZ7x9JtGAadxxErCNmAjNnLaKGbT1jsvOfP+oo7JOjs6L
P1HaKpsPVGA0bevcNoX2dObobJAOodm+RVtTV8QLOdPl4k5oOEUf8q1Jr4pZwktuLiOxQADIS
jiP1bm8SeNJBtoRC21pcKD+3JaVfslQBar0Xx6UVXLj5Gk0ot6nCVRig2LZ9fXznF5uhIyEHf
nKIIu2aImnYeK+g8LoeY8NpCAYAWDlhVzVQktuogYuqqMmw4RqwxfDhm8LG6eZEcj2vlffZPw
lwgsOntSog+2WZvf43xq8THJKcvpuTPCh0YfpRkSgZx/LuWD/nJOJI5gRHkDfsiIwcpkCJUYu
oJnX35jSfYyKOeMGa8XcaQKEho1c7osz7iuBcGTpncCt0uYtLWQpyKZ6LbqsLQCX8CFJn7OUx
er00B/V5iHNnI8KkjEBNDxiPDeuiPrRU/234YfewHrtdKBnXjmYJ9TXmp4+5cXmo9B3HVEil3
dT1Ura/iN27jQVrpEmkmSzBs2OdeCoLUozGFKfPriE/T0B0E55bs07OZwO4gCx4kfYCbNeZkG
rTbYPTht/JZilDngYhgjVqnwZ1jUcwD/NOijBKHiw01pMraQsewEvBSZ0JwkTatH3F/Pf1MAg
0rYKQVwTBkHjmOl+dq0eGe/rrquoBE73OlAuI9ScYRQwi1PhQnwTTPboJOFNGzQjN47Sr53fQ
s+4uqZC9TaP+TKUwHKvcEkz/8P6JZ7QnKCLu+RlG6kL3HrwaPdqB2GFmDyHZonnsqk
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: > And I tried to address exactly the same problem. I only
disagreed with > using the word "confusing". I think this is rather about
convenience. Then I won't insist. > This makes the behavior more predictable:
the user will know that all > buffers will be displayed in the most recently
used window, so the user > can switch to that window before continuing to
navi [...]
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
[212.95.5.146 listed in zen.spamhaus.org]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.22 listed in wl.mailspike.net]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.22 listed in list.dnswl.org]
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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: > And I tried to address exactly the same problem. I only
disagreed with > using the word "confusing". I think this is rather about
convenience. Then I won't insist. > This makes the behavior more predictable:
the user will know that all > buffers will be displayed in the most recently
used window, so the user > can switch to that window before continuing to
navi [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.22 listed in wl.mailspike.net]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.146 listed in zen.spamhaus.org]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.22 listed in list.dnswl.org]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.0 SPF_PASS SPF: sender matches SPF record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
> And I tried to address exactly the same problem. I only disagreed with
> using the word "confusing". I think this is rather about convenience.
Then I won't insist.
> This makes the behavior more predictable: the user will know that all
> buffers will be displayed in the most recently used window, so the user
> can switch to that window before continuing to navigate buffers.
Not really. The window switched to becomes the selected window and the
'mru' window used will be the window where the user was working before
the switch due to NOT-SELECTED being t.
>> Then maybe a separate category for rgrep buffers could help here.
>
> This is not about rgrep buffers.
Consider the completely untested action function below supposed to be
called with a (related-window . rgrep) alist argument.
martin
(defun display-buffer-in-related-window (buffer alist)
"Display BUFFER in a related window.
ALIST is an association list of action symbols and values. See
Info node `(elisp) Buffer Display Action Alists' for details of
such alists.
If ALIST has a non-nil `inhibit-same-window' entry, the selected
window is not usable. A dedicated window is usable only if it
already shows BUFFER. If ALIST contains a `related-window'
entry, the window specified by that entry (either a variable
or a value) is usable even if it never showed BUFFER before.
If ALIST contains a `reusable-frames' entry, its value determines
which frames to search for a usable window:
nil -- the selected frame (actually the last non-minibuffer frame)
A frame -- just that frame
`visible' -- all visible frames
0 -- all frames on the current terminal
t -- all frames.
If ALIST contains no `reusable-frames' entry, search just the
selected frame if `display-buffer-reuse-frames' and
`pop-up-frames' are both nil; search all frames on the current
terminal if either of those variables is non-nil.
If more than one window is usable according to these rules,
apply the following order of preference:
- Use the window specified by any `related-window' ALIST entry,
provided it is not the selected window.
- Use a window that showed BUFFER before, provided it is not the
selected window.
- Use the selected window if it is either specified by a
`related-window' ALIST entry or showed BUFFER before.
This is an action function for buffer display, see Info
node `(elisp) Buffer Display Action Functions'. It should be
called only by `display-buffer' or a function directly or
indirectly called by the latter."
(let* ((alist-entry (assq 'reusable-frames alist))
(inhibit-same-window
(cdr (assq 'inhibit-same-window alist)))
(frames (cond
(alist-entry (cdr alist-entry))
((window--pop-up-frames alist)
0)
(display-buffer-reuse-frames 0)
(t (last-nonminibuffer-frame))))
(first (and (frame-live-p frames) (frame-first-window frames)))
(related-window (cdr (assq 'related-window alist)))
best-window second-best-window window)
;; Scan windows whether they have a matching 'related-window'
;; parameter.
(catch 'best
(dolist (window (window-list-1 first 'nomini frames))
(when (and (eq (window-parameter window 'related-window)
related-window)
(not (window-dedicated-p window)))
(if (eq window (selected-window))
(unless inhibit-same-window
(setq second-best-window window))
(setq best-window window)
(throw 'best t)))))
;; When ALIST has a `related-window' entry, that entry may override
;; anything we found so far.
(when (and related-window (symbolp related-window)
(boundp related-window))
(setq related-window (symbol-value related-window)))
(when (and (setq window related-window)
(window-live-p window)
(or (eq buffer (window-buffer window))
(not (window-dedicated-p window))))
(if (eq window (selected-window))
(unless inhibit-same-window
(setq second-best-window window))
(setq best-window window)))
;; Return best or second best window found.
(when (setq window (or best-window second-best-window))
(window--display-buffer buffer window 'reuse alist))))
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.Received: (at 70949) by debbugs.gnu.org; 23 May 2024 17:34:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 23 13:34:43 2024 Received: from localhost ([127.0.0.1]:60108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sACKx-0005Ff-Dd for submit <at> debbugs.gnu.org; Thu, 23 May 2024 13:34:43 -0400 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:47839) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1sACKt-0005FZ-Vt for 70949 <at> debbugs.gnu.org; Thu, 23 May 2024 13:34:42 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id E3ABC240002; Thu, 23 May 2024 17:34:26 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#70949: display-buffer-choose-some-window In-Reply-To: <78dfee56-80b4-4ba7-a012-df31abd21743@HIDDEN> (martin rudalics's message of "Thu, 23 May 2024 09:22:07 +0200") Organization: LINKOV.NET References: <86jzjwqqmd.fsf@HIDDEN> <8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN> <86r0e32fnj.fsf@HIDDEN> <f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN> <867cft0xt2.fsf@HIDDEN> <ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN> <86ed9xvz3o.fsf@HIDDEN> <73251208-1e4c-4231-ae58-faf82363f241@HIDDEN> <86jzjoo23l.fsf@HIDDEN> <9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN> <86cypfm6s7.fsf@HIDDEN> <d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN> <86o78xm9y5.fsf@HIDDEN> <78dfee56-80b4-4ba7-a012-df31abd21743@HIDDEN> Date: Thu, 23 May 2024 20:27:13 +0300 Message-ID: <86sey8jv66.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 70949 Cc: 70949 <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 (-) >> With 'mru' the window used by 'display-buffer-use-some-window' >> is the last one. Here is the use case of the OP: >> >> When cycling through, say, a rgrep result buffer with n >> (next-error-no-select) and p (previous-error-no-select), file results >> are displayed in every open window, with the exception of the window >> containing the rgrep results themselves. > > That's the problem I tried to address in my first proposal: Displaying a > file in "every open window" can be confusing so we want to use always > the same non-selected window ... And I tried to address exactly the same problem. I only disagreed with using the word "confusing". I think this is rather about convenience. >> I'd rather have file results remain in just one window >> so that I can use other buffers while still viewing search results. > > ... but if, as you said earlier, the OP means "other windows" here, the > resulting behavior becomes unpredictable again because the 'mru' window > will change to the last "other" window of the user. This makes the behavior more predictable: the user will know that all buffers will be displayed in the most recently used window, so the user can switch to that window before continuing to navigate buffers. >>> I think the OP should use a side window to show "file results" which >>> would support the "remain in just one window" paradigm out of the box. >> >> Unfortunately, a side window is not a solution since after finishing >> navigating the search results, the window should remain normal. > > Then maybe a separate category for rgrep buffers could help here. This is not about rgrep buffers.
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.Received: (at 70949) by debbugs.gnu.org; 23 May 2024 07:22:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 23 03:22:25 2024 Received: from localhost ([127.0.0.1]:58682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sA2mP-0007or-Km for submit <at> debbugs.gnu.org; Thu, 23 May 2024 03:22:25 -0400 Received: from mout.gmx.net ([212.227.15.19]:56779) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rudalics@HIDDEN>) id 1sA2mM-0007oj-Iy for 70949 <at> debbugs.gnu.org; Thu, 23 May 2024 03:22:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1716448930; x=1717053730; i=rudalics@HIDDEN; bh=jMW8eIzX+fFRPdBislG1hJxmbXvKPf/EjwiV+zR9Uos=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=p/6RORKEaHtK5N1DPE8etJwzNhN0Qp6w05q+rOKtL825EqoOGShLG4jyDHAVzGjN QR4vsEiKfBixUbE+zYlyy8aCIfxWlkNRIZMkNxaUpZlbu28OHkkTJel5+vXHEMLUL hwKiUgC34xGUt1v9gPNeE/qWgjfwdTnKU8z5evIBYUp6GIKXm1cFImPh1jxJRjNi8 +ZLB7HX/N51Rdv4QqcxOON1W4qpOHzt7lKQ6mamxcXokrACx0VsHqlEI4p3yrwkh1 3GFhSyppm01/msBnimJxkgy6eowMPl4CRcHD4C9yKY/66KdEhtGCIliHX9/1vWr4s yCEjp+aCMR4eotfG5w== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.31.113] ([46.125.249.120]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MCKBc-1sIFyF3SiY-00CmAF; Thu, 23 May 2024 09:22:10 +0200 Message-ID: <78dfee56-80b4-4ba7-a012-df31abd21743@HIDDEN> Date: Thu, 23 May 2024 09:22:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#70949: display-buffer-choose-some-window To: Juri Linkov <juri@HIDDEN> References: <86jzjwqqmd.fsf@HIDDEN> <8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN> <86r0e32fnj.fsf@HIDDEN> <f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN> <867cft0xt2.fsf@HIDDEN> <ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN> <86ed9xvz3o.fsf@HIDDEN> <73251208-1e4c-4231-ae58-faf82363f241@HIDDEN> <86jzjoo23l.fsf@HIDDEN> <9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN> <86cypfm6s7.fsf@HIDDEN> <d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN> <86o78xm9y5.fsf@HIDDEN> Content-Language: en-US From: martin rudalics <rudalics@HIDDEN> In-Reply-To: <86o78xm9y5.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:Z3+YtXxJ1HHQ173Wu5m+OmyLkwz/rN57my+sdgug1Ukit3IUbER L7z9Vn5h4fvIHY+Ff6n7rJz3JB9BHcZ884swIXwyV8v1J4EKiamE5AzLarR2RYydqb94vvo X/RTH9kIjk0VpQlrfSoaTP0BKwW/OwjdRFlS6XuYMovBBSlIUK2TjdlkVFB9xwP6E8TKv3i BAWs559y3sEnKTxWi59wA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:E1hJ1MYaRbw=;h0SZgMHI+ZtXeh1KFWRCHnBTL8n Mt14t1sjxmc6kr5+FcfU7nRDrnOjuXT9EB0oea15vIlgA2nd5bbgFcrwYnIUXOxKsfuXq4k9Q ilIaLQ91rYvTme4rghH84A77m0hDOy3ZVaJAH4TFiQ21Ga+9N82Q6kYT0gTgqTjfrNUZ2Ugcm uP8LGSxTcYsSDX28S0f0x7cebkLGlx/PuWvjzTwE9xcsMILETOolgoS4r7uXRrG1q6CzXT6EA tGTvLWGLqegtHt0XHWvpy2iPoUNkfeE6VGA+FUkE+GcxjDGsw9aqqbiUe0ZzpdUyvFgJqz87H YkuzbxPwMIPL0RjSxK+UrR6QnZkRuXaoghHNAa3zys6ZgvJJAtsqZSC/TiS9iMoGxSaXnUqOr 4PCjeppCpXtkqWf0No6wWzlx2eHmHa8Dgb1+tOfY1K7GhRdQH+psgEel8dsjl+lrO/Ox0fQkA GNz5bS6Cde9OYnTD313EKw6v6HzDtzgEpEPNb+8G4mQPTVT8VNuoTL0PMe6UUePvu1Pj9eX1o y472/G3YR3tHji6EpOjBNhvt4TfvI26xfrQhDM5vezP5PSKjyHvzGYu+iiqWsrIF0Ah4mn2Kd qyREwwJ428oRPifX0Dcu/AXuK8eaNObBBTjayRcjmd8EqaxMrIuBEQQ0OWDzeHWMnpdAd8RgY pOMfoRTSRxQ2LzaWQ62E/z5UEQcBFZQQAEz+ABfBcs8PwdmM5fMqAdHxOubtWphLZHi0yLPmr FV72nyaRVC6vTWGlyx2S+IvIg8KA5ciIGHYt70kLRl8IZlXZ+Kl/WZjzfqzWdaWI/lfbIIbEI QPQ81TjTRzx48a06+mI0/9bjBsEvRmbOQt6Xr6svqNYRs= X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 70949 Cc: 70949 <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: -0.2 (/) > With 'mru' the window used by 'display-buffer-use-some-window' > is the last one. Here is the use case of the OP: > > When cycling through, say, a rgrep result buffer with n > (next-error-no-select) and p (previous-error-no-select), file results > are displayed in every open window, with the exception of the window > containing the rgrep results themselves. That's the problem I tried to address in my first proposal: Displaying a file in "every open window" can be confusing so we want to use always the same non-selected window ... > I'd rather have file results remain in just one window > so that I can use other buffers while still viewing search results. ... but if, as you said earlier, the OP means "other windows" here, the resulting behavior becomes unpredictable again because the 'mru' window will change to the last "other" window of the user. >> I think the OP should use a side window to show "file results" which >> would support the "remain in just one window" paradigm out of the box. > > Unfortunately, a side window is not a solution since after finishing > navigating the search results, the window should remain normal. Then maybe a separate category for rgrep buffers could help here. martin
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 23 May 2024 06:30:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 23 02:30:57 2024
Received: from localhost ([127.0.0.1]:58510 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sA1yb-0007H5-Fm
for submit <at> debbugs.gnu.org; Thu, 23 May 2024 02:30:57 -0400
Received: from relay3-d.mail.gandi.net ([217.70.183.195]:59825)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1sA1yW-0007Gp-HK
for 70949 <at> debbugs.gnu.org; Thu, 23 May 2024 02:30:52 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id B488A60004;
Thu, 23 May 2024 06:30:19 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#70949: display-buffer-choose-some-window
In-Reply-To: <d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN> (martin rudalics's
message of "Wed, 22 May 2024 09:39:38 +0200")
Organization: LINKOV.NET
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
<86r0e32fnj.fsf@HIDDEN>
<f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN>
<867cft0xt2.fsf@HIDDEN>
<ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN>
<86ed9xvz3o.fsf@HIDDEN>
<73251208-1e4c-4231-ae58-faf82363f241@HIDDEN>
<86jzjoo23l.fsf@HIDDEN>
<9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN>
<86cypfm6s7.fsf@HIDDEN>
<d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN>
Date: Thu, 23 May 2024 09:16:06 +0300
Message-ID: <86o78xm9y5.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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 (-)
>> Not quite right. It's not about a less confusing user experience.
>> Here is what the OP wrote for this request:
>>
>> I'd rather have file results remain in just one window so that I can use
>> other buffers while still viewing search results.
>>
>> Probably here would be better to say not "other buffers", but "other windows".
>
> Then we have a problem. If the OP wants to "use other windows" (and not
> just a single other window), the 'mru' will become one of these other
> windows and not the last one used by 'display-buffer-use-some-window'.
With 'mru' the window used by 'display-buffer-use-some-window'
is the last one. Here is the use case of the OP:
When cycling through, say, a rgrep result buffer with n
(next-error-no-select) and p (previous-error-no-select), file results
are displayed in every open window, with the exception of the window
containing the rgrep results themselves.
I'd rather have file results remain in just one window
so that I can use other buffers while still viewing search results.
> I think the OP should use a side window to show "file results" which
> would support the "remain in just one window" paradigm out of the box.
Unfortunately, a side window is not a solution since after finishing
navigating the search results, the window should remain normal.
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 22 May 2024 07:39:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 22 03:39:53 2024
Received: from localhost ([127.0.0.1]:54068 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s9gZl-0007Pc-FG
for submit <at> debbugs.gnu.org; Wed, 22 May 2024 03:39:53 -0400
Received: from mout.gmx.net ([212.227.17.21]:42075)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1s9gZj-0007PW-HJ
for 70949 <at> debbugs.gnu.org; Wed, 22 May 2024 03:39:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1716363579; x=1716968379; i=rudalics@HIDDEN;
bh=aCPy9TnM4kzfbcgybstEVWEVjhbYd+SGNdNBLjWN+9E=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc:
References:From:In-Reply-To:Content-Type:
Content-Transfer-Encoding:cc:content-transfer-encoding:
content-type:date:from:message-id:mime-version:reply-to:subject:
to;
b=gVqR8nQ0XKojdwtQJkqRt4MP1wghsuxILlrquJRfSUnmu2hIUY3TsJLwTegoofBB
N4Nlw5EGhbxk/PI+1FQ2EoipwtTBpahOSejpqlTn3z1GEpJpDzd5XhTVirXsuYAC5
Zbisi7/3Ij2t3cGqDlc+fNfbFq4/CkrU+MrHYpUCxhkk4nKxmvHzehuRSadWGrD7L
3YGUQv2pOJ08fwAN/PdHXLeWFpf6IHn+yrmFuij2kG2HqXYge/gVPqK+twtYevCqx
1pwrpKWDqBT5cdy0ni4ucZjUSG5u3ywpOmF2L9T9iRAOOw8uIhBxfaBIhxlNn3S/9
rM+rWoM4FrS4S0T6KA==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.189]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1MStCY-1ryBaX0pF0-00UN7U; Wed, 22
May 2024 09:39:39 +0200
Message-ID: <d64126b4-1c5e-48b7-9deb-cdbf88700c98@HIDDEN>
Date: Wed, 22 May 2024 09:39:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#70949: display-buffer-choose-some-window
To: Juri Linkov <juri@HIDDEN>
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
<86r0e32fnj.fsf@HIDDEN>
<f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN>
<867cft0xt2.fsf@HIDDEN>
<ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN>
<86ed9xvz3o.fsf@HIDDEN>
<73251208-1e4c-4231-ae58-faf82363f241@HIDDEN>
<86jzjoo23l.fsf@HIDDEN>
<9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN>
<86cypfm6s7.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86cypfm6s7.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:jwkn1mDgd0ek8fW3TU+JeUQhjETtt4lh3SseIeyDumy/Ko79cLq
LqVObv/t+Kg4pZzDSBEOaM0edqd/v0ZE4pWit1rLToslCSV5hotzKoEtA25Q/BdA6xP22Ql
f9deu4uJlu3S2WpqgKJGZGAntVa9rF0HzVYB37zH2HgfGJ0DZfM53zFw/CXF+McUJZoTRMd
cgr0lpkM3hRWVYL+U9PeQ==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:xhzjGxwVxus=;eSu9A0kmmhGbkhWupnK2BZEXwBO
C/Vdk24vnzy9h690Pp70QAwuCE6SfyIrvtFmjGbPf+vNloPhvyhHRvqEXEcnDHbLVCFfOAP0p
pZzYfsCmA5PrDO0BjLROzyG7e7nO7uf63eBkZ4DB5YM7X6Vv7gNUjptvgky5141Mv3b9ELd5W
l2OanzYAcpf8/DHYOhaBSMA5XJr4zDzV6C93fCKhHDN8kU2Q0NvqdnGPmU6xklOgMUQrZ/GaH
5t8ByAJzkLwR8c+5XJxfawaSqWrcMzBhbwhsE/cfSqyjSx3DLd040QNmq0ZELuB860WRz2OAW
m1mdluI2VNG/VUqhDDtA83AHqqVeMiFK1YZcG+ijZvA28PEusOoomsXZZuPZ5glEPPZx42Cac
ZZ8veTYLcva/72Wlz+SSPLbMY5ZbGB3DUbI5BI4AtwIyLoEyXyQ1lv8vgGD0jRWih+qNV9NRq
gdxqXaX92T8gAJc8IZz21+PAzZlMe4IIG+Y4b5wyMm2pnXZXdQz3IKkEEsRWqx0Bh5zdWp89N
Z1FY/v1mksvwyYhSYHOGvUzwHlFz/yrjiZQbu3pYxmxFrQIL0ICMe2CgEbgd9GI22yQH/3H/p
jZAHlSpdZ08YpQQKGxp5o2smE7vh8BfR32LtGW5JuBjiFqRTBsrmvr2/e6oziG/krbbFiegrS
0xWHQLaziGyuR/OUqN5ul3oUTZB70oa5XPJn3249QSnJhr/X+hiR1qwyiZsV+781fZjtT7BMq
XRu6vwV6adJWs2dGJUE+xeogwORbb6NEshB+m8ciJcECzC7vqg9tk9e89RH3pWHdfTrCX9bCz
lPCOJui5NviOPnqekZVF0qzeNBOcICLVVNvgZkBjF+c5E=
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: > Not quite right. It's not about a less confusing user
experience.
> Here is what the OP wrote for this request: > > I'd rather have file results
remain in just one window so that I can use > other [...]
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
[212.95.5.189 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.21 listed in wl.mailspike.net]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.21 listed in list.dnswl.org]
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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: > Not quite right. It's not about a less confusing user experience.
> Here is what the OP wrote for this request: > > I'd rather have file results
remain in just one window so that I can use > other [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.21 listed in wl.mailspike.net]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[212.95.5.189 listed in zen.spamhaus.org]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.21 listed in list.dnswl.org]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.0 SPF_PASS SPF: sender matches SPF record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
> Not quite right. It's not about a less confusing user experience.
> Here is what the OP wrote for this request:
>
> I'd rather have file results remain in just one window so that I can use
> other buffers while still viewing search results.
>
> Probably here would be better to say not "other buffers", but "other windows".
Then we have a problem. If the OP wants to "use other windows" (and not
just a single other window), the 'mru' will become one of these other
windows and not the last one used by 'display-buffer-use-some-window'.
I think the OP should use a side window to show "file results" which
would support the "remain in just one window" paradigm out of the box.
martin
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 21 May 2024 17:25:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 21 13:25:42 2024
Received: from localhost ([127.0.0.1]:50241 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s9TF8-0001EQ-8g
for submit <at> debbugs.gnu.org; Tue, 21 May 2024 13:25:42 -0400
Received: from relay2-d.mail.gandi.net ([217.70.183.194]:33517)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1s9TF3-0001EK-Pg
for 70949 <at> debbugs.gnu.org; Tue, 21 May 2024 13:25:41 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 8876240003;
Tue, 21 May 2024 17:25:05 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#70949: display-buffer-choose-some-window
In-Reply-To: <9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN> (martin rudalics's
message of "Tue, 21 May 2024 10:21:14 +0200")
Organization: LINKOV.NET
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
<86r0e32fnj.fsf@HIDDEN>
<f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN>
<867cft0xt2.fsf@HIDDEN>
<ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN>
<86ed9xvz3o.fsf@HIDDEN>
<73251208-1e4c-4231-ae58-faf82363f241@HIDDEN>
<86jzjoo23l.fsf@HIDDEN>
<9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN>
Date: Tue, 21 May 2024 20:18:56 +0300
Message-ID: <86cypfm6s7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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 (-)
> +The above describes the behavior when @code{some-window} @var{alist}
> +entry is @code{lru} or @code{nil} which is the default. But when,
> +for example, @code{display-buffer-base-action} is customized to
> +@w{@code{(nil . ((some-window . mru)))}}, then the value @code{mru}
> +means that this function will prefer the most recently used window
> +that is useful to display several buffers in the same window
> +in a layout with more than two windows.
>
> This is ambiguous - we should emphasize that these buffers are not
> displayed at the same time. I'd write something like the following:
>
> The default behavior might become irritating when 'display-buffer' is
> used to display a number of related buffers in a row.
>
> Consider a configuration of two or more windows where a user wants to
> consult, in a non-selected window, one after the other, the results of a
> query spread among several buffers. With the 'lru' strategy, Emacs
> might continuously choose another window because the least recently used
> window changes with every call of 'display-buffer-use-some-window'.
> With the 'mru' strategy, the window chosen would always remain the same,
> resulting in a less confusing user experience.
>
> If I got it right ...
Not quite right. It's not about a less confusing user experience.
Here is what the OP wrote for this request:
I'd rather have file results remain in just one window so that I can use
other buffers while still viewing search results.
Probably here would be better to say not "other buffers", but "other windows".
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 21 May 2024 08:21:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 21 04:21:32 2024
Received: from localhost ([127.0.0.1]:47825 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s9KkW-0005DT-GR
for submit <at> debbugs.gnu.org; Tue, 21 May 2024 04:21:32 -0400
Received: from mout.gmx.net ([212.227.17.20]:48511)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1s9KkR-0005DE-I7
for 70949 <at> debbugs.gnu.org; Tue, 21 May 2024 04:21:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1716279675; x=1716884475; i=rudalics@HIDDEN;
bh=22jbYF1Kh6NNpfC9WlUyO7tfHJ8z2ZTK52YSUd0VWh4=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc:
References:From:In-Reply-To:Content-Type:
Content-Transfer-Encoding:cc:content-transfer-encoding:
content-type:date:from:message-id:mime-version:reply-to:subject:
to;
b=dcO6DZHPoLQThioh8N7eQbN+93PxEMongNPm4KJqYofRq6SxzrXAeFBy8w4+yNGT
wadFCJYisRwFKDwi2vO7lFjkuIfNVmQm+Hf2DFXVAnUFCgIHvyj8nVqKh+RGQoYBs
ZGewXngcshvDnEdTDeH2Faq8AKkJuEYnrN2UOz5EARMxspH6COs4puhkzfibOVMQs
eOBdJzwlkZT6swYZdL4FyPTX3IpkSYpl6M1GG6qejzqIrXhgfUMQ+JAY5tpcH2iRe
bGXT40HaSplmVE0l7HJLr/alxylA9OtBoL5XXwJ9VpZU/gnmiEBVK9Np5VYv6BKSP
tW5eIah0Nz84tjVSsA==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.108]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1MatRT-1shHqi30dn-00cNSe; Tue, 21
May 2024 10:21:15 +0200
Message-ID: <9e29cbbc-65ee-4dd8-8a41-539946e19a7c@HIDDEN>
Date: Tue, 21 May 2024 10:21:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#70949: display-buffer-choose-some-window
To: Juri Linkov <juri@HIDDEN>
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
<86r0e32fnj.fsf@HIDDEN>
<f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN>
<867cft0xt2.fsf@HIDDEN>
<ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN>
<86ed9xvz3o.fsf@HIDDEN>
<73251208-1e4c-4231-ae58-faf82363f241@HIDDEN>
<86jzjoo23l.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86jzjoo23l.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:8/ZBTPwdwlnUJSOMxS6iKtlSO6aO09gLUk8OHvctGdB0l7OwTKy
Hr//dZxcsPtsYI+qpVzkfHsXgiT+2I1E8Il8uqFHdQy/8hCeYbgg2P3aZ9ldOKn6uSGBRRK
+D4z3F/4zKtDJrRMMNfpP/SfIWrGo0Go2Kap/b1XU7mmwAs6NYByvrBfaguQ1hAQNQwkRej
M+0Lf4ZhpIyBGb5dmXydA==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:WTv7bXuBbps=;im4z7mewg41TsGH/Zytawp/kQSA
3LlWO79o5ho+asHmoU8EWbjDuN6PKzx5yCt7yfega8V8Oce491jfcN1m3F8li0WOR+ttV5noX
MjA37o/FEJWwggz01dMtuui9VmaPMtDOyvdT8TByY7H7OvoUJuAX5yiY4AfeJCJaHbQTDVCXH
DHldOSdPkaIcqMPsW5BledQsNqtxcnWjIB635k35JzW0ZQJU8ltNvox6xTrFpW+P+vsPRk+oW
wkDWxPjTgLVa6fYaqqPtOaQc998Y16/isQ5m19Rj1sKMB+W8ZLOUsbjZxxNqKW11layFBhy6B
TgjznuBi0bj2wYWepi/aw3gekvZ6M3bqTct8YN/XRVf1it1DSiVS0ADP0casV9PoBIQoO0Pup
LCgVYt+oVnejsR69EjUu9EmcScUojopZUX7V/74RSXJTtGpReP4Dp/E/gecvxtuWulNYAEahW
/K/Vib03g6FjFVnqezgCD/jWDSSodzvakmdFojkrSu5w1KR4QVdostpkJq9UGJ6Efx+QUCeDY
zAQ1yqp0X/OJ7co3yQdi6IddncoMP7p5e7wWemOZqv+hS1rbWVvEooAO1GpsQbfIWvUbQOYrP
JO4yxQSX4pRv93Yoa4vX88gcONpjCRPI1ZtLCaVKMPTNQ/IYux23G+hYZ542fkuxnM2/FS82h
nYR2ADyCcsfX31GsGYcOGAbZZ7cRHeMAs3bc8qL66lPt+mANpfEo+qWjA9yS9PqbhF4Fa1/Ty
dMOIpvo3xWWpB2pgp5VCcsjhXkMVBO1Z9StE0BCCc3awaHg674n0sNJE+tR2pVPP3p0TbjfbL
0EaUsqvOBNfPgn+NHIWGAh+Z5xIhbD3GsMLOrgkdImiL0=
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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 (-)
+The above describes the behavior when @code{some-window} @var{alist}
+entry is @code{lru} or @code{nil} which is the default. But when,
+for example, @code{display-buffer-base-action} is customized to
+@w{@code{(nil . ((some-window . mru)))}}, then the value @code{mru}
+means that this function will prefer the most recently used window
+that is useful to display several buffers in the same window
+in a layout with more than two windows.
This is ambiguous - we should emphasize that these buffers are not
displayed at the same time. I'd write something like the following:
The default behavior might become irritating when 'display-buffer' is
used to display a number of related buffers in a row.
Consider a configuration of two or more windows where a user wants to
consult, in a non-selected window, one after the other, the results of a
query spread among several buffers. With the 'lru' strategy, Emacs
might continuously choose another window because the least recently used
window changes with every call of 'display-buffer-use-some-window'.
With the 'mru' strategy, the window chosen would always remain the same,
resulting in a less confusing user experience.
If I got it right ...
martin
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 20 May 2024 17:02:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 20 13:02:29 2024
Received: from localhost ([127.0.0.1]:43695 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s96P6-0004Wm-MJ
for submit <at> debbugs.gnu.org; Mon, 20 May 2024 13:02:29 -0400
Received: from relay8-d.mail.gandi.net ([217.70.183.201]:58079)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1s96P1-0004We-KI
for 70949 <at> debbugs.gnu.org; Mon, 20 May 2024 13:02:27 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 2604D1BF203;
Mon, 20 May 2024 17:02:10 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#70949: display-buffer-choose-some-window
In-Reply-To: <73251208-1e4c-4231-ae58-faf82363f241@HIDDEN> (martin rudalics's
message of "Mon, 20 May 2024 10:01:13 +0200")
Organization: LINKOV.NET
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
<86r0e32fnj.fsf@HIDDEN>
<f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN>
<867cft0xt2.fsf@HIDDEN>
<ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN>
<86ed9xvz3o.fsf@HIDDEN>
<73251208-1e4c-4231-ae58-faf82363f241@HIDDEN>
Date: Mon, 20 May 2024 19:54:54 +0300
Message-ID: <86jzjoo23l.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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 (-)
--=-=-=
Content-Type: text/plain
>> + `display-buffer-use-some-window' should choose. The possible choices
>> + are `lru' or nil (the default) to select the least recently used window,
>> + and `mru' to select the most recently used window . When a function, it
>
> I'd say "It can also be a function that takes two arguments ..."
>
>> + takes two arguments: a buffer and an alist, and should return the window
>> + where to display the buffer. When the value is `lru', it avoids
>> + selecting windows that are not full-width and windows on another frame.
>> + When the value is `mru', it avoids selecting an already selected window
>> + and windows on another frame.
>
> I'd say "..., it does not consider the selected window and windows on
> any frame but the selected one."
>
> But the more important thing is to tell users how this can help to fix
> problems like the one that triggered this thread. A short description
> in the doc-string and a more elaborated one with an example in the Elisp
> manual in the description of 'display-buffer-use-some-window' and in the
> "Action Alists for Buffer Display" section.
Thanks for suggestions, here is a complete patch:
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=some-window.patch
diff --git a/doc/lispref/windows.texi b/doc/lispref/windows.texi
index 61e72eae680..efffb0d3f3f 100644
--- a/doc/lispref/windows.texi
+++ b/doc/lispref/windows.texi
@@ -2805,6 +2805,14 @@ Buffer Display Action Functions
some other window, preferably a large window on some visible frame. It
can fail if all windows are dedicated to other buffers (@pxref{Dedicated
Windows}).
+
+The above describes the behavior when @code{some-window} @var{alist}
+entry is @code{lru} or @code{nil} which is the default. But when,
+for example, @code{display-buffer-base-action} is customized to
+@w{@code{(nil . ((some-window . mru)))}}, then the value @code{mru}
+means that this function will prefer the most recently used window
+that is useful to display several buffers in the same window
+in a layout with more than two windows.
@end defun
@defun display-buffer-use-least-recent-window buffer alist
@@ -3358,6 +3366,16 @@ Buffer Display Action Alists
will display the buffer. @code{display-buffer-no-window} is the only
action function that cares about this entry.
+@vindex some-window@r{, a buffer display action alist entry}
+@item some-window
+If the value is @code{nil} or @code{lru}, @code{display-buffer-use-some-window}
+prefers the least recently used window while avoiding selecting windows
+that are not full-width and windows on another frame. If the value is
+@code{mru}, it prefers the most recently used window not considering the
+selected window and windows on any frame but the selected one. If the
+value is a function, it is called with two arguments: a buffer and an
+alist, and should return the window where to display the buffer.
+
@vindex body-function@r{, a buffer display action alist entry}
@item body-function
The value must be a function taking one argument (a displayed window).
diff --git a/etc/NEWS b/etc/NEWS
index 4e52d4dccb2..cc2405ca09a 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -306,6 +306,14 @@ right-aligned to is controlled by the new user option
** Windows
++++
+*** New action alist entry 'some-window' for 'display-buffer'.
+It defines which window 'display-buffer-use-some-window' should prefer.
+For example, when 'display-buffer-base-action' is customized to
+'(nil . ((some-window . mru)))' then any buffer will be displayed
+in the same most recently used window on a layout with more
+than two windows.
+
+++
*** New action alist entry 'category' for 'display-buffer'.
If the caller of 'display-buffer' passes '(category . symbol)'
diff --git a/lisp/window.el b/lisp/window.el
index e709e978cc9..1549fba6f2e 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -7845,6 +7850,18 @@ display-buffer
parameters to give the chosen window.
`allow-no-window' -- A non-nil value means that `display-buffer'
may not display the buffer and return nil immediately.
+ `some-window' -- This entry defines which window
+ `display-buffer-use-some-window' should choose. The possible choices
+ are `lru' or nil (the default) to select the least recently used window,
+ and `mru' to select the most recently used window. It can also be
+ a function that takes two arguments: a buffer and an alist, and should
+ return the window where to display the buffer. If the value is `lru',
+ it avoids selecting windows that are not full-width and windows on
+ another frame. If the value is `mru', it does not consider the
+ selected window and windows on any frame but the selected one.
+ It's useful to customize `display-buffer-base-action' to
+ `(nil . ((some-window . mru))) when you want to display buffers in
+ the same non-selected window in a layout with more than two windows.
`body-function' -- A function called with one argument - the
displayed window. It is called after the buffer is
displayed, and before `window-height', `window-width'
@@ -8734,20 +8751,33 @@ display-buffer-use-some-window
event that a window on another frame is chosen, avoid raising
that frame.
+If ALIST contains a non-nil `some-window' entry, then prefer the least
+recently used window if the entry's value is `lru' or nil, or the most
+recently used window if it's `mru'. If the value is a function, it is
+called with two arguments: a buffer and an alist, and should return
+the window where to display the buffer.
+
This is an action function for buffer display, see Info
node `(elisp) Buffer Display Action Functions'. It should be
called only by `display-buffer' or a function directly or
indirectly called by the latter."
(let* ((not-this-window (cdr (assq 'inhibit-same-window alist)))
+ (some-window-method (cdr (assq 'some-window alist)))
(frame (or (window--frame-usable-p (selected-frame))
(window--frame-usable-p (last-nonminibuffer-frame))))
(window
;; Reuse an existing window.
- (or (display-buffer--lru-window
- ;; If ALIST specifies 'lru-frames' or 'window-min-width'
- ;; let them prevail.
- (append alist `((lru-frames . ,frame)
- (window-min-width . full-width))))
+ (or (cond
+ ((memq some-window-method '(nil lru))
+ (display-buffer--lru-window
+ ;; If ALIST specifies 'lru-frames' or 'window-min-width'
+ ;; let them prevail.
+ (append alist `((lru-frames . ,frame)
+ (window-min-width . full-width)))))
+ ((eq some-window-method 'mru)
+ (get-mru-window nil nil t))
+ ((functionp some-window-method)
+ (funcall some-window-method buffer alist)))
(let ((window (get-buffer-window buffer 'visible)))
(unless (and not-this-window
(eq window (selected-window)))
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 20 May 2024 08:01:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 20 04:01:28 2024
Received: from localhost ([127.0.0.1]:40814 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s8xxY-0006Bd-I8
for submit <at> debbugs.gnu.org; Mon, 20 May 2024 04:01:28 -0400
Received: from mout.gmx.net ([212.227.15.19]:46245)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1s8xxV-0006BP-AX
for 70949 <at> debbugs.gnu.org; Mon, 20 May 2024 04:01:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1716192074; x=1716796874; i=rudalics@HIDDEN;
bh=Efqt9uidzkBRnAYdhrqrlJUxe3uxpPToysfbC46gd9c=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc:
References:From:In-Reply-To:Content-Type:
Content-Transfer-Encoding:cc:content-transfer-encoding:
content-type:date:from:message-id:mime-version:reply-to:subject:
to;
b=DK8wXqLxLGOggu2/2iTza2YQMisclww6r+4h0ZbHaCUiv1atXra4Isvh4/YFK8VN
zFTT9QF1nDajvcXEA84OIAwsA/mVcaYxQFA8S0x0x5JG2vf2/LLltyhWZjoLljkLU
qwqc2uDMMZowg3xJa0RtvVNvg2+sj9lDiEmgcX25DXewBv4fdFxXYRcwyX/GNXTNw
clYE9EGc6Hm/ojAABvFZ0R6ifDZHeG6ZcYCr9NKIuJ0UTb2BMfIsLNUvCgT5OJumm
zo5WapIpAIM0iNbHxTvmwEk2zzGR9q9rG2GT0lKuraQ3MEXHdyEjGwQv6ZtHLYVOK
7jXcaZMhucz2b1/nqA==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([213.142.97.251]) by mail.gmx.net (mrgmx004
[212.227.17.190]) with ESMTPSA (Nemesis) id 1N8GMk-1se1Ri0cDo-017TTN; Mon, 20
May 2024 10:01:14 +0200
Message-ID: <73251208-1e4c-4231-ae58-faf82363f241@HIDDEN>
Date: Mon, 20 May 2024 10:01:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#70949: display-buffer-choose-some-window
To: Juri Linkov <juri@HIDDEN>
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
<86r0e32fnj.fsf@HIDDEN>
<f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN>
<867cft0xt2.fsf@HIDDEN>
<ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN>
<86ed9xvz3o.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86ed9xvz3o.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:x31SpU2t0BaCi+z5+yP8ZqLwgI59Hi8BruMKTl9zpe3iFFRi3a3
MGgpMrwuSgETyptcJGNp5dW1aTW86fW2kHEnOEVkqyFLwLgGe3ZDFs8dXuBialqvj4eGuP7
LW7cFinxxaVY8959eCB87Hh5bJugGnMBZ+15YZIzaYBv7j9BaYYDAhVxBPIDX2RMu9PQ3Ll
OkkwwkgCycF9F5MeeXcCA==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:2d9FGBpnnvc=;O44XHnNfIYBI7La9SqT3QqOSxTt
Z3BXofan+5O9wJOfHhfkHPdkY0IO8/PZB3JR9JzR8GThVCI0VbW4iOgPHT+sfbs6tcXOvxNsk
5ABdBTNbiLlUdih9/0UVEibRRTWt2eURqxVU2GHUACg+b3lYsHXFq/NGn4nb+fgJ73jOLed4D
7QRBHlnLYxlwVJNGjQq6juSjRR3dTYm+p5GEULNJa6zvJR9YDzgDFbuyqym6QM/mcx8wGDC+m
UPZxfzkkCJg/+AaKVO2hwZPGOhvcjqwoW+FYHPP5W0+sAl8K++HKUfPTxKuD+IEBowgjwu6Af
/SDyZEdgB9htC0KwQ5UiVWQSY2q6PYWgp48NRwQ3drRdQ7BP0wHgs7LubAbSFKlsQW35DVNAe
SAlA3UBPS4YWhKj76ZbsJbPj0lFjZCGfJbsiP3hrjGPMu/y+oTmw7puytWYuArRgF+j4ZXHEW
LOAN6MNoUiCryJIZpEBuF1JvHgZSPAfdAuO0aANqIKNuFIaEi2uKpt5ZHtGWWLc5oYlALII8f
BfmifGQvPNvyz0cp3whCd0oeG94hkYYDJG6ObhDs+KGJgnRe54Hbq5n5DPx+TwdClaHLm4bCd
8y5PCF36q4KtclCYbgeC7+vzHTPgQpYlvndmlJOMTI1qrjErUAzQWJg6dIlI2XK1NLzrEJEQ8
uB74EhwC1OuW8oYggKYIkdoNZVzWiOKkXyfHB91hQXWA5Gga7uL/rDobZTuG8cAOD6xf2ng47
jF3eVA5kYaYcPEPA0bmv97a8gCADb+ByWiDVn5eukKjy3DAEk3MASry1tS8ttsn6DRc7eLikG
NE4bIvEUd2TnaQQuDo9tan5R/OKAUnbmInVIOHRzKQoBA=
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: > + `display-buffer-use-some-window' should choose. The
possible
choices > + are `lru' or nil (the default) to select the least recently used
window, > + and `mru' to select the most recently used wi [...]
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
[213.142.97.251 listed in zen.spamhaus.org]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.19 listed in wl.mailspike.net]
-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]
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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: > + `display-buffer-use-some-window' should choose. The possible
choices > + are `lru' or nil (the default) to select the least recently used
window, > + and `mru' to select the most recently used wi [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.19 listed in wl.mailspike.net]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[213.142.97.251 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_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.0 SPF_PASS SPF: sender matches SPF record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
> + `display-buffer-use-some-window' should choose. The possible choices
> + are `lru' or nil (the default) to select the least recently used window,
> + and `mru' to select the most recently used window . When a function, it
I'd say "It can also be a function that takes two arguments ..."
> + takes two arguments: a buffer and an alist, and should return the window
> + where to display the buffer. When the value is `lru', it avoids
> + selecting windows that are not full-width and windows on another frame.
> + When the value is `mru', it avoids selecting an already selected window
> + and windows on another frame.
I'd say "..., it does not consider the selected window and windows on
any frame but the selected one."
But the more important thing is to tell users how this can help to fix
problems like the one that triggered this thread. A short description
in the doc-string and a more elaborated one with an example in the Elisp
manual in the description of 'display-buffer-use-some-window' and in the
"Action Alists for Buffer Display" section.
martin
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 20 May 2024 06:17:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 20 02:17:49 2024
Received: from localhost ([127.0.0.1]:40317 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s8wLE-0004xn-Lj
for submit <at> debbugs.gnu.org; Mon, 20 May 2024 02:17:49 -0400
Received: from relay1-d.mail.gandi.net ([217.70.183.193]:44513)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1s8wL8-0004xh-NJ
for 70949 <at> debbugs.gnu.org; Mon, 20 May 2024 02:17:47 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 3BB9D240005;
Mon, 20 May 2024 06:17:10 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#70949: display-buffer-choose-some-window
In-Reply-To: <ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN> (martin rudalics's
message of "Sat, 18 May 2024 11:21:52 +0200")
Organization: LINKOV.NET
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
<86r0e32fnj.fsf@HIDDEN>
<f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN>
<867cft0xt2.fsf@HIDDEN>
<ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN>
Date: Mon, 20 May 2024 09:15:11 +0300
Message-ID: <86ed9xvz3o.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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 (-)
--=-=-=
Content-Type: text/plain
>> I already considered adding an alist entry, but the problem is that
>> it's not clear where users would put it to cover display of all buffers.
>> But I could reconsider such solution, if you will suggest a suitable place
>> for users to add such an alist like (some-window . mru) for all buffers.
>
> Why would that be a problem? Any "(some-window . mru)" entry would
> exclusively affect the execution of 'display-buffer-use-some-window'.
> So what would be wrong with
>
> (customize-set-variable
> 'display-buffer-alist
> (cons '(".*" nil (some-window . mru)) display-buffer-alist))
Or maybe users could customize base-action:
(setq display-buffer-base-action '(nil . ((some-window . mru))))
Ok, here is a new patch with a new alist entry:
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=some-window-method.patch
diff --git a/lisp/window.el b/lisp/window.el
index 8feeba0d83e..5f9dec1dc25 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -7851,7 +7856,16 @@ display-buffer
and `preserve-size' are applied. The function is supposed
to fill the window body with some contents that might depend
on dimensions of the displayed window.
- `post-command-select-window' -- A non-nil value means that after the
+ `some-window' -- This entry defines which window
+ `display-buffer-use-some-window' should choose. The possible choices
+ are `lru' or nil (the default) to select the least recently used window,
+ and `mru' to select the most recently used window . When a function, it
+ takes two arguments: a buffer and an alist, and should return the window
+ where to display the buffer. When the value is `lru', it avoids
+ selecting windows that are not full-width and windows on another frame.
+ When the value is `mru', it avoids selecting an already selected window
+ and windows on another frame.
+ `post-command-select-window' -- A non-nil value means that after the
current command is executed and the hook `post-command-hook' is called,
the window displayed by this function will be selected. A nil value
means that if functions like `pop-to-buffer' selected another window,
@@ -8739,15 +8753,22 @@ display-buffer-use-some-window
called only by `display-buffer' or a function directly or
indirectly called by the latter."
(let* ((not-this-window (cdr (assq 'inhibit-same-window alist)))
+ (some-window-method (cdr (assq 'some-window alist)))
(frame (or (window--frame-usable-p (selected-frame))
(window--frame-usable-p (last-nonminibuffer-frame))))
(window
;; Reuse an existing window.
- (or (display-buffer--lru-window
- ;; If ALIST specifies 'lru-frames' or 'window-min-width'
- ;; let them prevail.
- (append alist `((lru-frames . ,frame)
- (window-min-width . full-width))))
+ (or (cond
+ ((memq some-window-method '(nil lru))
+ (display-buffer--lru-window
+ ;; If ALIST specifies 'lru-frames' or 'window-min-width'
+ ;; let them prevail.
+ (append alist `((lru-frames . ,frame)
+ (window-min-width . full-width)))))
+ ((eq some-window-method 'mru)
+ (get-mru-window nil nil t))
+ ((functionp some-window-method)
+ (funcall some-window-method buffer alist)))
(let ((window (get-buffer-window buffer 'visible)))
(unless (and not-this-window
(eq window (selected-window)))
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 18 May 2024 09:22:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 18 05:22:12 2024
Received: from localhost ([127.0.0.1]:60540 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s8GGX-0000Bi-KF
for submit <at> debbugs.gnu.org; Sat, 18 May 2024 05:22:12 -0400
Received: from mout.gmx.net ([212.227.17.22]:43813)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1s8GGR-0000BG-LA
for 70949 <at> debbugs.gnu.org; Sat, 18 May 2024 05:22:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1716024113; x=1716628913; i=rudalics@HIDDEN;
bh=3eVJFrcSqhqPvATNnZQa+FzDqGQwt7POfYBc7SKV78g=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc:
References:From:In-Reply-To:Content-Type:
Content-Transfer-Encoding:cc:content-transfer-encoding:
content-type:date:from:message-id:mime-version:reply-to:subject:
to;
b=FKrd5Hj2CUt00jQQnDbD/VAvECQQ3WCLYRn+2srbhcyriGvZ+4Cc1LfdA/w/TnyZ
teVuvirL72pmVFUgS7SidKIU4cmE+weNkslDGxLwTX5OUVY3YBG0mvvj0wlYlCR+L
tX/J9hIjKt9JKS3+mnTdgn4KOuQb3ElAJSkppy6/7T1v51+DfFR1h1b2uNMiEIvsX
uOxD7lg5MIn1XQL7Hovlq6anv6v4ylgOHAmYSnPbvz0FWP+j9Wt/OJrTnk4P//NWN
+r+Sr1D4vQE/1W0wtAWehvVjYBmU/b8k0jI8lIMF8bBQDy8p3655fLPZmlFXTJsJb
uk6GmnGlj1TPCU7ZPg==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([212.95.5.97]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1Mlf4c-1squTD2seg-00ikOD; Sat, 18
May 2024 11:21:53 +0200
Message-ID: <ed3fffa8-8742-428e-aebf-61949f67e854@HIDDEN>
Date: Sat, 18 May 2024 11:21:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#70949: display-buffer-choose-some-window
To: Juri Linkov <juri@HIDDEN>
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
<86r0e32fnj.fsf@HIDDEN>
<f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN>
<867cft0xt2.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <867cft0xt2.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:j8fISv3pAcM+6Z4b2vu8kvTGq+1anIAGLHk4giWVPZIyvI6jrP2
Cq559J7HE44oJccD5ErQ6JpiIWCmSB4PTa3s+5Dxh2eTfoa/frEU7VFtToDlHTLIIN2pEmG
GzxPYft4vZ1zwGaHdd3ZG/6C1r0FfOxq1O65J1oFP8BFF932dlInpRNvJ8/zdEqHOXGoVvj
azu5uiIqYb9K6Tyi+8ARg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:/a7ulFYESpM=;kJ3Mw92n2HG5EIBKVRrpVchOTom
Hv6ox3oy6AY2EB8CHPNMwLyzmT0nCThAPYihF5wHBLIez0f+L4iT7vKjpZhsLeH7kbJmcMrNi
pTO20+zUKrxukFin5EyY/hdgZBn+Tw3nFTb8k+iUFcRYO2uW7/kw67jZL3kyqdBHBuUn58YPE
VF0AIw8nXg3j23jw9JjnbQ2JyKbsyEOtL2vF1x3Z59jDjL/WdM3O8jxE2wux9Zv2byaokEDPq
wPaskI1oprrFRrL8E0xkKBdBqfJ640Y9wJ3s7xkqQ2Xp3vNaQvOwSAXYk4QbH73cmko3YFJ6U
CRpKTqtPu8ixQQlBTsBRfGHSrqAWqOA63Wd03dc5ow9PN3yTZjgtsGs1gOlD4i8NnaGCXvvSc
Nw46r4G/28pCDDqTI8WmcbQeVhT2sT5CtNAcn0STSUhA7Q15dX5Ki3WWC851EehkrM67AtzKj
nQak1rphAe8PD3Zoahc0GID+4HXpqr8oEQFFtGF2+8j1V+FbPHMoP8B4UFq4XG4IIRaD/Febl
ag0h+IcWQQZWPX/deCbmxyIScUDlVOotSbLim0GTpriBK6e9vamBrdKQqk+V4K78NfJNxEMvv
SedSp4UNPakv4uELwMq12ru0Kd4NoDSOY0sG70dQNbXSmEG2eiSdZEQRiq4lECSAF+4tkYAn/
4JnJgsQEh8vWmrZzxyDTTgUzTJF7WC106FVXNf2SACk8ISMPSm8zBe1mOA0Hps4umEUSdKm36
7AOWbpe/cSkgx3THKek8Zbzo7W91G8rf1hnRHXbJWSEZZx2CoDSj0fgeAvrjPKbg1/jx2YXTD
S35STJJdotivh170IAF4vfYg2LheNWNZYvuzJsms1opO0=
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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 (-)
> I already considered adding an alist entry, but the problem is that
> it's not clear where users would put it to cover display of all buffers.
> But I could reconsider such solution, if you will suggest a suitable place
> for users to add such an alist like (some-window . mru) for all buffers.
Why would that be a problem? Any "(some-window . mru)" entry would
exclusively affect the execution of 'display-buffer-use-some-window'.
So what would be wrong with
(customize-set-variable
'display-buffer-alist
(cons '(".*" nil (some-window . mru)) display-buffer-alist))
martin
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 17 May 2024 06:52:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 17 02:52:35 2024
Received: from localhost ([127.0.0.1]:53485 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s7rSF-0002Pd-FI
for submit <at> debbugs.gnu.org; Fri, 17 May 2024 02:52:35 -0400
Received: from relay1-d.mail.gandi.net ([217.70.183.193]:42069)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1s7rSD-0002PV-9D
for 70949 <at> debbugs.gnu.org; Fri, 17 May 2024 02:52:33 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id E337D240006;
Fri, 17 May 2024 06:52:03 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#70949: display-buffer-choose-some-window
In-Reply-To: <f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN> (martin rudalics's
message of "Thu, 16 May 2024 10:20:46 +0200")
Organization: LINKOV.NET
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
<86r0e32fnj.fsf@HIDDEN>
<f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN>
Date: Fri, 17 May 2024 09:40:49 +0300
Message-ID: <867cft0xt2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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 (-)
--=-=-=
Content-Type: text/plain
>>> Also, we should mention the constraints used for 'lru' and that 'mru'
>>> avoids the selected window here.
>>
>> Sorry, I don't understand what constraints. The docstring of
>> 'display-buffer-use-some-window' doesn't mention any 'lru' constraints.
>
> For historical reasons, 'display-buffer-use-some-window' avoids windows
> that are not full-width and windows on another frame via
>
> (append alist `((lru-frames . ,frame)
> (window-min-width . full-width))))
>
> The default behavior can be overridden with appropriate alist entries
> which are not mentioned in the doc-string but are described in the Elisp
> manual. Your option should mention them because they defy a "strict"
> interpretation of 'lru'.
Thanks for explanations, now these constraints are documented.
> BTW, you could have, instead of an option, provided a 'some-window'
> alist entry with the possible values 'lru', 'mru' or a function. Why
> did you prefer the option?
I already considered adding an alist entry, but the problem is that
it's not clear where users would put it to cover display of all buffers.
But I could reconsider such solution, if you will suggest a suitable place
for users to add such an alist like (some-window . mru) for all buffers.
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline;
filename=display-buffer-use-some-window-method.patch
diff --git a/lisp/window.el b/lisp/window.el
index 8feeba0d83e..67af4753a70 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -8721,6 +8726,24 @@ display-buffer--lru-window
(setq best-window window))))))
(or best-window second-best-window)))
+(defcustom display-buffer-use-some-window-method 'lru
+ "Which window `display-buffer-use-some-window' should choose.
+The possible choices are `lru' (the default) to select the least
+recently used window, and `mru' to select the most recently used
+window . When a function, it takes two arguments: a buffer and
+an alist, and should return the window where to display the buffer.
+
+When the value is `lru', it avoids selecting windows that are
+not full-width and windows on another frame.
+When the value is `mru', it avoids selecting an already selected window
+and windows on another frame."
+ :type '(choice (const :tag "Least recently used" lru)
+ (const :tag "Most recently used" mru)
+ (function :tag "Custom function"))
+ :group 'windows
+ :group 'frames
+ :version "30.1")
+
(defun display-buffer-use-some-window (buffer alist)
"Display BUFFER in an existing window.
Search for a usable window, set that window to the buffer, and
@@ -8743,11 +8767,17 @@ display-buffer-use-some-window
(window--frame-usable-p (last-nonminibuffer-frame))))
(window
;; Reuse an existing window.
- (or (display-buffer--lru-window
- ;; If ALIST specifies 'lru-frames' or 'window-min-width'
- ;; let them prevail.
- (append alist `((lru-frames . ,frame)
- (window-min-width . full-width))))
+ (or (cond
+ ((eq display-buffer-use-some-window-method 'lru)
+ (display-buffer--lru-window
+ ;; If ALIST specifies 'lru-frames' or 'window-min-width'
+ ;; let them prevail.
+ (append alist `((lru-frames . ,frame)
+ (window-min-width . full-width)))))
+ ((eq display-buffer-use-some-window-method 'mru)
+ (get-mru-window nil nil t))
+ ((functionp display-buffer-use-some-window-method)
+ (funcall display-buffer-use-some-window-method buffer alist)))
(let ((window (get-buffer-window buffer 'visible)))
(unless (and not-this-window
(eq window (selected-window)))
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 16 May 2024 08:21:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 16 04:21:00 2024
Received: from localhost ([127.0.0.1]:47408 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s7WMF-00085J-Ti
for submit <at> debbugs.gnu.org; Thu, 16 May 2024 04:21:00 -0400
Received: from mout.gmx.net ([212.227.17.22]:44357)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1s7WMD-00085B-GS
for 70949 <at> debbugs.gnu.org; Thu, 16 May 2024 04:20:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1715847648; x=1716452448; i=rudalics@HIDDEN;
bh=XRltfS8eE29D0qqKouD1r36h0lCIOPKmEX2KMPFssx8=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc:
References:From:In-Reply-To:Content-Type:
Content-Transfer-Encoding:cc:content-transfer-encoding:
content-type:date:from:message-id:mime-version:reply-to:subject:
to;
b=lkwqnjFSBIVTGXmUFRkTpILb3tNvsz3mWnfJu7UbbivqA3GJWyaxNr3Y2oicSB9J
AWdIAzWXgaF9c8byzBukV7DvwHQoewCVSwl5ydVwIt8Hf1rCrBZM8UiweuQWDdFV7
6V7hSy3zGt7Jp87eAYkiUd/45SZoNCa24ibfIc3fgT4F8Qo1jTzRUq2xsJJ+r7qVN
8MYXazl3+Gu1fkuT0exIFbj54SL7a4/Om2rllduX/e3mPA6XbkEoIJIGHb9wR0ih5
vekGFh5zlXQ3/8f7O42XxpoeJFE1wP7Zs9syI8dZZQWX2oXR/NfYNc4FV7u2qEagc
LgvesxmFnTzchpbP4Q==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([213.142.97.244]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1MHoRK-1sKECM0Brq-00Eti2; Thu, 16
May 2024 10:20:48 +0200
Message-ID: <f956a47c-56c7-4005-93b4-885c03b05d08@HIDDEN>
Date: Thu, 16 May 2024 10:20:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#70949: display-buffer-choose-some-window
To: Juri Linkov <juri@HIDDEN>
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
<86r0e32fnj.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86r0e32fnj.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:Z1TTpb5vkMrlg2Su8GwIYk0GbM1NB2peJC47746+6FD89jzOo5e
16uXa/yM3gYoYo7L31zaocxsvAGOH4tstQOYWJYo5u4ExHMGmwUk/db8dWNi0C7g00/D/DW
EtZ0HVrL5RoCumo/1lnwgxzDHo3nkB53qMdv52+lKCpy9uZuv/TjdTML/slTU/u2K5rvrEq
sL9oFGPZjJkt9C4jgxr/w==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:zA2ME8HLpek=;mKJaccy4SVo4GLpjf5oYe/QN1LN
LSm+3WyzbV/Gsjw2VS9RhladchqFznbLn+OdV3YrEIlO3YqoVatlLa/9OdiA8TSBZcqY72620
HE8WPoAcb1y8jD4dYYw7xE1OGAHHLjmWOdTCL960Wa5JyNPErP9UuKj2dXLK/7BylBEvo3LMi
0ybVr1DRN+nfsZiSbdBEJoabbTguNFR8pa8VNey5X7a85xXeodJ2zzghMkeCuG/CA8+oLoLQ4
gh2xLeYa5w30A7k5wg7tNFFQ1x9Wm5LV84RbJ6iguowSWVdsyd7WGOS7mwXBhJU8mJfb6cjMz
Crx6Y60CedsZKolVS5L/6JE1NN9rFCpXxltCox3xNqPvVmEivtU9xGj4c3z/FqbsBPc6jO+Ec
aWK6t9ReRhFnoQy22dxB4CSjDRqfMMPiZN6rezbMXuA4GXH57NsyGUl82IoLnHjsOgOM7k1Vk
kumwynCfdnGdC3CdRg3LlcYQfnKOub54hVKroboVa++tcFL+68kWdICx55tlLs/1BQxndll5o
doLLhbppH4Ag1W11pLu3iD+Rm8NWn/2aXnboFHCiF4bS4DRIpSbAudDTThtGEzNxpR89W1f6N
p1P+LUJWrmrwgb9dr1N2TG6MoWgpbk8aQRPSmm+349rQsmaVICsvrUaETYoTYc5h0UALWUGHL
ZQd7QZ57BRrgOzeX/0SqQdEXHwee/xEq/Stcw/JQzStzDjw01xqeXGf1McMBDFNMe/o9n3ZfB
qeeU00uFjI+9DaMfvDcL4fRoqyQRlTkVvZijP8ZgdUk1sIBAZdjDjDnuic3w4nVoFPP+B1Bef
tJQ43VmNs/+KPKRECDfXJI/sojoSv6l4hP2yDvrp5bsfk=
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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 (-)
>> Also, we should mention the constraints used for 'lru' and that 'mru'
>> avoids the selected window here.
>
> Sorry, I don't understand what constraints. The docstring of
> 'display-buffer-use-some-window' doesn't mention any 'lru' constraints.
For historical reasons, 'display-buffer-use-some-window' avoids windows
that are not full-width and windows on another frame via
(append alist `((lru-frames . ,frame)
(window-min-width . full-width))))
The default behavior can be overridden with appropriate alist entries
which are not mentioned in the doc-string but are described in the Elisp
manual. Your option should mention them because they defy a "strict"
interpretation of 'lru'.
BTW, you could have, instead of an option, provided a 'some-window'
alist entry with the possible values 'lru', 'mru' or a function. Why
did you prefer the option?
martin
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 15 May 2024 17:15:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 15 13:15:17 2024
Received: from localhost ([127.0.0.1]:43303 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s7IDk-0007PD-JS
for submit <at> debbugs.gnu.org; Wed, 15 May 2024 13:15:16 -0400
Received: from relay6-d.mail.gandi.net ([217.70.183.198]:39709)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1s7IDT-0007OI-Sw
for 70949 <at> debbugs.gnu.org; Wed, 15 May 2024 13:15:15 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id E639BC0008;
Wed, 15 May 2024 17:14:50 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#70949: display-buffer-choose-some-window
In-Reply-To: <8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN> (martin rudalics's
message of "Wed, 15 May 2024 10:06:39 +0200")
Organization: LINKOV.NET
References: <86jzjwqqmd.fsf@HIDDEN>
<8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
Date: Wed, 15 May 2024 19:49:28 +0300
Message-ID: <86r0e32fnj.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 70949
Cc: 70949 <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 (-)
--=-=-=
Content-Type: text/plain
>> +(defcustom display-buffer-choose-some-window 'lru
>> + "How to choose an existing window.
>> +This defines a strategy of choosing some window
>> +by `display-buffer-use-some-window'.
>> +
>> +The possible choices are `lru' (the default) to select the least recently
>> +used window on that frame, and `mru' to select the most recently used
>> +window on that frame. When a function, it takes two arguments: a buffer
>> +and an alist, and should return the window where to display the buffer."
>
> I'd call the option 'display-buffer-use-some-window-method' so it's more
> clear that it pertains to 'display-buffer-use-some-window'. As for the
> first line of the doc-string I'd write
>
> "Which window `display-buffer-use-some-window' should choose."
Ok, done in this patch.
> Also, we should mention the constraints used for 'lru' and that 'mru'
> avoids the selected window here.
Sorry, I don't understand what constraints. The docstring of
'display-buffer-use-some-window' doesn't mention any 'lru' constraints.
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline;
filename=display-buffer-use-some-window-method.patch
diff --git a/lisp/window.el b/lisp/window.el
index 3935908fdb4..01c8429500d 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -8726,6 +8726,20 @@ display-buffer--lru-window
(setq best-window window))))))
(or best-window second-best-window)))
+(defcustom display-buffer-use-some-window-method 'lru
+ "Which window `display-buffer-use-some-window' should choose.
+The possible choices are `lru' (the default) to select the least
+recently used window, and `mru' to select the most recently used
+window (not taking into account the selected window). When a function,
+it takes two arguments: a buffer and an alist, and should return the
+window where to display the buffer."
+ :type '(choice (const :tag "Least recently used" lru)
+ (const :tag "Most recently used" mru)
+ (function :tag "Custom function"))
+ :group 'windows
+ :group 'frames
+ :version "30.1")
+
(defun display-buffer-use-some-window (buffer alist)
"Display BUFFER in an existing window.
Search for a usable window, set that window to the buffer, and
@@ -8748,11 +8762,17 @@ display-buffer-use-some-window
(window--frame-usable-p (last-nonminibuffer-frame))))
(window
;; Reuse an existing window.
- (or (display-buffer--lru-window
- ;; If ALIST specifies 'lru-frames' or 'window-min-width'
- ;; let them prevail.
- (append alist `((lru-frames . ,frame)
- (window-min-width . full-width))))
+ (or (cond
+ ((eq display-buffer-use-some-window-method 'lru)
+ (display-buffer--lru-window
+ ;; If ALIST specifies 'lru-frames' or 'window-min-width'
+ ;; let them prevail.
+ (append alist `((lru-frames . ,frame)
+ (window-min-width . full-width)))))
+ ((eq display-buffer-use-some-window-method 'mru)
+ (get-mru-window t t t))
+ ((functionp display-buffer-use-some-window-method)
+ (funcall display-buffer-use-some-window-method buffer alist)))
(let ((window (get-buffer-window buffer 'visible)))
(unless (and not-this-window
(eq window (selected-window)))
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at 70949) by debbugs.gnu.org; 15 May 2024 08:06:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 15 04:06:51 2024
Received: from localhost ([127.0.0.1]:41910 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s79f1-0002kJ-9i
for submit <at> debbugs.gnu.org; Wed, 15 May 2024 04:06:51 -0400
Received: from mout.gmx.net ([212.227.15.18]:47393)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1s79ey-0002kB-IB
for 70949 <at> debbugs.gnu.org; Wed, 15 May 2024 04:06:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1715760400; x=1716365200; i=rudalics@HIDDEN;
bh=NQNgE397zYKY50MRJ7nNiJKHCg1pz5MNcaRsY51vfgM=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:
References:From:In-Reply-To:Content-Type:
Content-Transfer-Encoding:cc:content-transfer-encoding:
content-type:date:from:message-id:mime-version:reply-to:subject:
to;
b=WS4C97Z6Gkc9DlDSUbZwSEt8j6v05++TlKrLjzxMVQc+9ueHukJaKTrc5hJxIcpV
ucir/v6mf2sgM5Zw5gSxYj06g+pU/4o8YUjgkCP7M18C2MgrIBnFLWQZaMiZ3jyA7
tfmDM7MkQ/01wT8hxrNe5bkPWMsdZafXEfJ+2FS7BA8awZ792bnbRd2sqATIozVXV
0a4l4w4zwNUQstbEZfk0yVfjAURiWvFp0DS/02esHbTRgjJvbd7nRlcdhTpIYWSCd
wa58dWTCRUD+91RgyN8UTSZm2ffvObhEFePjK0V7vQdD1Ox5qtDMPSguvlck+Nsk8
GWO0WyOo+4RIIQqCaA==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([213.142.97.111]) by mail.gmx.net (mrgmx005
[212.227.17.190]) with ESMTPSA (Nemesis) id 1Mq2nA-1suDze2kXC-00n80m; Wed, 15
May 2024 10:06:40 +0200
Message-ID: <8d1947c7-a4d1-4920-8638-f8ae17acfe65@HIDDEN>
Date: Wed, 15 May 2024 10:06:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#70949: display-buffer-choose-some-window
To: Juri Linkov <juri@HIDDEN>, 70949 <at> debbugs.gnu.org
References: <86jzjwqqmd.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86jzjwqqmd.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:r6XrUGCD3RBBLlc9fN6OCuFaA0nTVidOzbcf2fWYrV1HMzu+hqX
KISNa16DkknzSEXTOJMTsKx8Xx30Xrbfis7SUGjY3YHLdhHlFDXodHhiZt7TGcbQh30TFuC
L6P3W8oUhsjzkLEAtMVVThqEMzXAbqyIQrHZPZP0cJJ3KuioaWGsq/sB9euDJLe7wun1+Pd
YOjXMh13wd7RWFKUmiR7w==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:btoMdbh0YBQ=;4IhRTSS6pVayLkwEDvZGLRmsBTX
lo0/LP9ei3spUMKfyN1oGE00HExjtK5TWWYIR9oTd1Wyj0hppeTtwKI1p27td0VxcCcqy7CTI
KpNOTKr78U+5AJufE4Hc5yw1RncIl37kzquFZohCpwmixyZUmtVixlFeElhp41ge7uIkQcGoV
dsMoZLyQk+b7zE62sO2w3Lx/lc8pn3FxfE29LAABTR+qaPTZdXvZRYs9KIMCXeHM6b/ANg5rJ
5XsHE8fcgpGntlj9ihPZYYcB5sgCFr8Y7vq4iR4Ync/8xcCmfa5/wXdihWCyAUuNkQhcah0Nf
SjZjpWwS9DRqSlB6R8Z0tAe4TjFWYt07Uzvc6GTaFbP6FV5J4VXrPZ/0b8uvA4CloaFCoFP1w
tJdDTgbnTILY7hP52JSzinkiE41ivvvPVV8elbHYUrYxTyLw4k1lmCex7xtMgHFX4VTocgq1E
5Dns8fFkUOX4C60y09PcZz36uzJZDLbikSwJu29ucOs/8Tk57YNduYDK9+9zAWU+l8+f2kpqG
07rx5BeRsrJbd9LD40K7so3AylY4dM3lOirFouJ4Q+LdM0gMoHvZNMRJuamyeGS0gw3Ffft99
bz6mXH16aof9g+xBh3G4FD5qm3qkWhvDhjHjvcsxY5ZlrSRLRHGjzpig/5Wpl4nabtJhfM7zD
j4e/7J0JGP8K2f3AbPwuX1yL7n6u/tUTDNX/VsO78Be0KU80icufqN1P14Kl0q6jdqns8PE0i
uaxFBX+4kkoPsNSqKhnwIwkda/A3oOJC01yrnc5hE/UxZ0Fcf74Mobj0brCJCjKrU2CrdJHVt
fqyPAzcWftsS1SVMM9jzdr6R/+TNRWVe+p/ayQzESyB8M=
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: > +(defcustom display-buffer-choose-some-window 'lru > +
"How to choose an existing window. > +This defines a strategy of choosing
some window > +by `display-buffer-use-some-window'. > + > +The possi [...]
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
[213.142.97.111 listed in zen.spamhaus.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.18 listed in wl.mailspike.net]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.15.18 listed in list.dnswl.org]
X-Debbugs-Envelope-To: 70949
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: > +(defcustom display-buffer-choose-some-window 'lru > +
"How to choose an existing window. > +This defines a strategy of choosing
some window > +by `display-buffer-use-some-window'. > + > +The possi [...]
Content analysis details: (1.9 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.18 listed in wl.mailspike.net]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[213.142.97.111 listed in zen.spamhaus.org]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.15.18 listed in list.dnswl.org]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.0 SPF_PASS SPF: sender matches SPF record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
> +(defcustom display-buffer-choose-some-window 'lru
> + "How to choose an existing window.
> +This defines a strategy of choosing some window
> +by `display-buffer-use-some-window'.
> +
> +The possible choices are `lru' (the default) to select the least recently
> +used window on that frame, and `mru' to select the most recently used
> +window on that frame. When a function, it takes two arguments: a buffer
> +and an alist, and should return the window where to display the buffer."
I'd call the option 'display-buffer-use-some-window-method' so it's more
clear that it pertains to 'display-buffer-use-some-window'. As for the
first line of the doc-string I'd write
"Which window `display-buffer-use-some-window' should choose."
Also, we should mention the constraints used for 'lru' and that 'mru'
avoids the selected window here.
martin
bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 14 May 2024 16:59:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 14 12:59:41 2024
Received: from localhost ([127.0.0.1]:40371 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1s6vV7-0001xw-GN
for submit <at> debbugs.gnu.org; Tue, 14 May 2024 12:59:41 -0400
Received: from lists.gnu.org ([209.51.188.17]:60826)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1s6vV4-0001xq-Na
for submit <at> debbugs.gnu.org; Tue, 14 May 2024 12:59:40 -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 <juri@HIDDEN>) id 1s6vV3-0001QR-9T
for bug-gnu-emacs@HIDDEN; Tue, 14 May 2024 12:59:37 -0400
Received: from relay6-d.mail.gandi.net ([2001:4b98:dc4:8::226])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <juri@HIDDEN>) id 1s6vV1-0004OO-Fw
for bug-gnu-emacs@HIDDEN; Tue, 14 May 2024 12:59:37 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id DB347C0006
for <bug-gnu-emacs@HIDDEN>; Tue, 14 May 2024 16:59:31 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: display-buffer-choose-some-window
Organization: LINKOV.NET
X-Debbugs-Cc: martin rudalics <rudalics@HIDDEN>
Date: Tue, 14 May 2024 19:56:27 +0300
Message-ID: <86jzjwqqmd.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-GND-Sasl: juri@HIDDEN
Received-SPF: pass client-ip=2001:4b98:dc4:8::226;
envelope-from=juri@HIDDEN; helo=relay6-d.mail.gandi.net
X-Spam_score_int: -24
X-Spam_score: -2.5
X-Spam_bar: --
X-Spam_report: (-2.5 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
TRACKER_ID=0.1 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.5 (-)
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: -2.5 (--)
--=-=-=
Content-Type: text/plain
Addressing the request in help-gnu-emacs quoted below:
>> When cycling through, say, a rgrep result buffer with n
>> (next-error-no-select) and p (previous-error-no-select), file results
>> are displayed in every open window, with the exception of the window
>> containing the rgrep results themselves.
>>
>> I'd rather have file results remain in just one window so that I can use
>> other buffers while still viewing search results. Is this possible?
>>
>> How would I go about this? Are there any better options?
>
> The problem is that the first thing that
> 'display-buffer-use-some-window' tries to do
> is to find the least recently used window
> with 'display-buffer--lru-window'.
>
> I think this behavior should be customizable with a new option,
> so that you could prefer always to use
> the most recently used window.
here is a patch that adds such option that allows to customize
what window display-buffer-use-some-window should prefer:
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline;
filename=display-buffer-choose-some-window.patch
diff --git a/lisp/window.el b/lisp/window.el
index 8feeba0d83e..d34e369167e 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -8721,6 +8726,22 @@ display-buffer--lru-window
(setq best-window window))))))
(or best-window second-best-window)))
+(defcustom display-buffer-choose-some-window 'lru
+ "How to choose an existing window.
+This defines a strategy of choosing some window
+by `display-buffer-use-some-window'.
+
+The possible choices are `lru' (the default) to select the least recently
+used window on that frame, and `mru' to select the most recently used
+window on that frame. When a function, it takes two arguments: a buffer
+and an alist, and should return the window where to display the buffer."
+ :type '(choice (const :tag "Least recently used" lru)
+ (const :tag "Most recently used" mru)
+ (function :tag "Custom function"))
+ :group 'windows
+ :group 'frames
+ :version "30.1")
+
(defun display-buffer-use-some-window (buffer alist)
"Display BUFFER in an existing window.
Search for a usable window, set that window to the buffer, and
@@ -8743,11 +8764,17 @@ display-buffer-use-some-window
(window--frame-usable-p (last-nonminibuffer-frame))))
(window
;; Reuse an existing window.
- (or (display-buffer--lru-window
- ;; If ALIST specifies 'lru-frames' or 'window-min-width'
- ;; let them prevail.
- (append alist `((lru-frames . ,frame)
- (window-min-width . full-width))))
+ (or (cond
+ ((eq display-buffer-choose-some-window 'lru)
+ (display-buffer--lru-window
+ ;; If ALIST specifies 'lru-frames' or 'window-min-width'
+ ;; let them prevail.
+ (append alist `((lru-frames . ,frame)
+ (window-min-width . full-width)))))
+ ((eq display-buffer-choose-some-window 'mru)
+ (get-mru-window nil nil t))
+ ((functionp display-buffer-choose-some-window)
+ (funcall display-buffer-choose-some-window buffer alist)))
(let ((window (get-buffer-window buffer 'visible)))
(unless (and not-this-window
(eq window (selected-window)))
--=-=-=--
Juri Linkov <juri@HIDDEN>:rudalics@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.rudalics@HIDDEN, bug-gnu-emacs@HIDDEN:bug#70949; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.