From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#70949: display-buffer-choose-some-window Date: Mon, 27 May 2024 20:52:53 +0300 Organization: LINKOV.NET Message-ID: <86plt7dyvu.fsf@mail.linkov.net> References: <86jzjwqqmd.fsf@mail.linkov.net> <8d1947c7-a4d1-4920-8638-f8ae17acfe65@gmx.at> <86r0e32fnj.fsf@mail.linkov.net> <867cft0xt2.fsf@mail.linkov.net> <86ed9xvz3o.fsf@mail.linkov.net> <73251208-1e4c-4231-ae58-faf82363f241@gmx.at> <86jzjoo23l.fsf@mail.linkov.net> <9e29cbbc-65ee-4dd8-8a41-539946e19a7c@gmx.at> <86cypfm6s7.fsf@mail.linkov.net> <86o78xm9y5.fsf@mail.linkov.net> <78dfee56-80b4-4ba7-a012-df31abd21743@gmx.at> <86sey8jv66.fsf@mail.linkov.net> <86zfsfqgtl.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1859"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: 70949@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 27 20:01:22 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sBeew-0000NQ-4Z for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 May 2024 20:01:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sBeea-0007rV-DH; Mon, 27 May 2024 14:01:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sBeeV-0007lQ-Ao for bug-gnu-emacs@gnu.org; Mon, 27 May 2024 14:00:55 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sBeeU-0003fN-WB for bug-gnu-emacs@gnu.org; Mon, 27 May 2024 14:00:55 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sBeec-0000AY-Cj for bug-gnu-emacs@gnu.org; Mon, 27 May 2024 14:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 May 2024 18:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70949 X-GNU-PR-Package: emacs Original-Received: via spool by 70949-submit@debbugs.gnu.org id=B70949.1716832802461 (code B ref 70949); Mon, 27 May 2024 18:01:02 +0000 Original-Received: (at 70949) by debbugs.gnu.org; 27 May 2024 18:00:02 +0000 Original-Received: from localhost ([127.0.0.1]:45213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sBedd-00006q-Ei for submit@debbugs.gnu.org; Mon, 27 May 2024 14:00:02 -0400 Original-Received: from relay8-d.mail.gandi.net ([217.70.183.201]:38077) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sBedb-00006d-Kh for 70949@debbugs.gnu.org; Mon, 27 May 2024 14:00:00 -0400 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id DEA051BF204; Mon, 27 May 2024 17:59:43 +0000 (UTC) In-Reply-To: (martin rudalics's message of "Sun, 26 May 2024 10:54:20 +0200") X-GND-Sasl: juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:286061 Archived-At: >> 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?