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: Thu, 30 May 2024 10:54:35 +0200 Message-ID: References: <86jzjwqqmd.fsf@mail.linkov.net> <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> <431cc3a7-141e-414f-8650-72771609c407@gmx.at> <86ed9jhkox.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="9018"; 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 Thu May 30 10:55:17 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 1sCbZ6-0002BE-WD for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 30 May 2024 10:55:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sCbYj-0000vF-7f; Thu, 30 May 2024 04:54:53 -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 1sCbYi-0000v0-74 for bug-gnu-emacs@gnu.org; Thu, 30 May 2024 04:54:52 -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 1sCbYh-0008De-Uq for bug-gnu-emacs@gnu.org; Thu, 30 May 2024 04:54:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sCbYs-0008Fl-7E for bug-gnu-emacs@gnu.org; Thu, 30 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: Thu, 30 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.171705929631699 (code B ref 70949); Thu, 30 May 2024 08:55:02 +0000 Original-Received: (at 70949) by debbugs.gnu.org; 30 May 2024 08:54:56 +0000 Original-Received: from localhost ([127.0.0.1]:53445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sCbYl-0008FC-Ht for submit@debbugs.gnu.org; Thu, 30 May 2024 04:54:55 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:56367) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sCbYj-0008En-Jg for 70949@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@gmx.at; 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 Original-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 Content-Language: en-US In-Reply-To: <86ed9jhkox.fsf@mail.linkov.net> X-Provags-ID: V03:K1:dUumML+/atIJ1DNauB8HBhanYBUV4At8h8NEg/x9S9rRZPsOfYH SNHSraGIq/OMVVdWJHabq2z3FUbSIf5Osa35ix84quPcvGmkK3MpB/fG8sgR4vw8pQV/nJk NKtpPnSKPsKe+Awxw7Z0FJp9UsFj2mkBG7PHFKSmKx2nRRt1qA95a7yC46+J11skU6fFua+ vopZ9Z5UjzE30kfQfky0g== 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+ 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:286205 Archived-At: > 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