From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#70949: display-buffer-choose-some-window Date: Sun, 26 May 2024 10:54:20 +0200 Message-ID: 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> Reply-To: martin rudalics Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16556"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 70949@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 26 10:55:12 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 1sB9eo-00043D-R2 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 26 May 2024 10:55:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sB9ea-00057F-Dd; Sun, 26 May 2024 04:54:56 -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 1sB9eY-00056y-Vx for bug-gnu-emacs@gnu.org; Sun, 26 May 2024 04:54: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 1sB9eY-0000Fu-OD for bug-gnu-emacs@gnu.org; Sun, 26 May 2024 04:54:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sB9eg-0000MC-FV for bug-gnu-emacs@gnu.org; Sun, 26 May 2024 04:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 May 2024 08:55: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.17167136801322 (code B ref 70949); Sun, 26 May 2024 08:55:02 +0000 Original-Received: (at 70949) by debbugs.gnu.org; 26 May 2024 08:54:40 +0000 Original-Received: from localhost ([127.0.0.1]:38336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sB9eJ-0000LE-Nj for submit@debbugs.gnu.org; Sun, 26 May 2024 04:54:40 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:33641) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sB9eG-0000Kx-FF for 70949@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@gmx.at; 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 Original-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 Content-Language: en-US In-Reply-To: <86zfsfqgtl.fsf@mail.linkov.net> X-Provags-ID: V03:K1:QeJYm57s9sm1u3xix9Uom17e4vmVK9Ja1MidvA8llZdpKBXsNuF GckCTFVIoq4+JZ8Fs3Gi7ejXQpp05GQapJCBfusUH1gvY7JlH9jX4eFxOX4Ls7SNxBO5Lvw FQYRusrwZNGi1x1xkxBbjGFolNV2KKoJHTiwRdpsHTBSl7i/6GVJpxGspukAEZXYwjP2w9a ao1Qo2N8wc3LRx27lQipg== 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+ 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:285937 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? > 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