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: Wed, 29 May 2024 10:49:37 +0200 Message-ID: <431cc3a7-141e-414f-8650-72771609c407@gmx.at> 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> <86plt7dyvu.fsf@mail.linkov.net> <963412d9-85b9-4afe-a29f-52981f24aa5b@gmx.at> <86zfsaaqm1.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="28002"; 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 Wed May 29 10:50:14 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 1sCF0g-00071x-JW for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 29 May 2024 10:50:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sCF0O-00087q-MD; Wed, 29 May 2024 04:49: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 1sCF0M-00084J-6c for bug-gnu-emacs@gnu.org; Wed, 29 May 2024 04:49:54 -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 1sCF0L-0000TJ-UW for bug-gnu-emacs@gnu.org; Wed, 29 May 2024 04:49:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sCF0U-00044y-47 for bug-gnu-emacs@gnu.org; Wed, 29 May 2024 04:50: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: Wed, 29 May 2024 08:50: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.171697259815663 (code B ref 70949); Wed, 29 May 2024 08:50:02 +0000 Original-Received: (at 70949) by debbugs.gnu.org; 29 May 2024 08:49:58 +0000 Original-Received: from localhost ([127.0.0.1]:52406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sCF0P-00044Z-SA for submit@debbugs.gnu.org; Wed, 29 May 2024 04:49:58 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:35751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sCF0N-00044H-5S for 70949@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@gmx.at; 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 Original-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 Content-Language: en-US In-Reply-To: <86zfsaaqm1.fsf@mail.linkov.net> X-Provags-ID: V03:K1:YKJUyKNStBDUukRtApMeLaJ4npSXI+fKSYF+cKvza4QYTBrtARn Gskcd1OPjghCA0+vCobwFIHZym1hUrdTLMRVyspVaYoT4SKXIP5AxMzostIsq5zJ2VF1L47 3iRGZU4jM82vDfamIv7Hty82iIDWrYSwNDLyKTrR5p77jdFq+Jl2t5BFr9hbrwc18bZ16Ar /YxoURX1/FB3/UsDZZhcA== 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/C2Yx94u4dL7jvMYsIfqW1SgrROJbk1FrW718ZuaK 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:286142 Archived-At: > 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