From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#32825: 27.0.50; Deterministic window management Date: Tue, 13 Nov 2018 01:39:35 +0200 Organization: LINKOV.NET Message-ID: <87wophvpag.fsf@mail.linkov.net> References: <874leeaiah.fsf@mail.linkov.net> <87h8h0juwn.fsf@mail.linkov.net> <5BDC0E38.5020901@gmx.at> <87d0rl7kl1.fsf@mail.linkov.net> <5BDEB6BA.5000307@gmx.at> <87y3a8jz6v.fsf@mail.linkov.net> <5BE00EB1.6090107@gmx.at> <87sh0fxkih.fsf@mail.linkov.net> <5BE154F5.4050902@gmx.at> <87r2fxsvl5.fsf@mail.linkov.net> <5BE2AF02.40909@gmx.at> <87sh0cva5h.fsf@mail.linkov.net> <5BE3F981.8000002@gmx.at> <8736sbmdtv.fsf@mail.linkov.net> <5BE54FBE.306@gmx.at> <874lcqmu6u.fsf@web.de> <5BE582D4.8010201@gmx.at> <874lcok62x.fsf@mail.linkov.net> <5BE7EE09.3020003@gmx.at> <87pnvbpejc.fsf@mail.linkov.net> <5BE93DB5.8070804@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1542067564 21185 195.159.176.226 (13 Nov 2018 00:06:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 13 Nov 2018 00:06:04 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: Michael Heerdegen , 32825@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 13 01:06:00 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gMMDP-0005NV-KN for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Nov 2018 01:05:59 +0100 Original-Received: from localhost ([::1]:51268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gMMFV-0000pF-SD for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Nov 2018 19:08:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gMMFE-0000jL-Fe for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2018 19:07:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gMM9b-0004WS-4k for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2018 19:02:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44182) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gMM9a-0004WB-Fq for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2018 19:02:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gMM9a-0006Jq-D4 for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2018 19:02:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Nov 2018 00:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32825 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32825-submit@debbugs.gnu.org id=B32825.154206729124219 (code B ref 32825); Tue, 13 Nov 2018 00:02:02 +0000 Original-Received: (at 32825) by debbugs.gnu.org; 13 Nov 2018 00:01:31 +0000 Original-Received: from localhost ([127.0.0.1]:48433 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gMM95-0006IZ-B2 for submit@debbugs.gnu.org; Mon, 12 Nov 2018 19:01:31 -0500 Original-Received: from eastern.maple.relay.mailchannels.net ([23.83.214.55]:8489) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gMM92-0006IP-9V for 32825@debbugs.gnu.org; Mon, 12 Nov 2018 19:01:28 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D1ACB5031A8; Tue, 13 Nov 2018 00:01:26 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a77.g.dreamhost.com (unknown [100.96.19.78]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 7D8AD502F56; Tue, 13 Nov 2018 00:01:26 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a77.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Tue, 13 Nov 2018 00:01:26 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Celery-Abiding: 2d0fb51450458503_1542067286724_807923007 X-MC-Loop-Signature: 1542067286724:1957766441 X-MC-Ingress-Time: 1542067286724 Original-Received: from pdx1-sub0-mail-a77.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a77.g.dreamhost.com (Postfix) with ESMTP id 47DA67FF38; Mon, 12 Nov 2018 16:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=6poOEaQerZc399IxenMRircRqVw=; b= bm+mCGil9bjyUSnRLykkm/ldSv/OljDkjUE9shaBgO+0ZxhhpRyU6z9BB8HDGUJo HPwNoMNio7ec1aAhpn0V4UVxCgUL8RYBPB9yUltP4AZ3S3cNcXVzoUbf0NsYdgIC 8d4ITNX3DImkzEKi0b5ghud1RNaoGx+ue8HQN/5THLg= Original-Received: from mail.jurta.org (m91-129-107-244.cust.tele2.ee [91.129.107.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a77.g.dreamhost.com (Postfix) with ESMTPSA id BDD127FF2D; Mon, 12 Nov 2018 16:01:23 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a77 In-Reply-To: <5BE93DB5.8070804@gmx.at> (martin rudalics's message of "Mon, 12 Nov 2018 09:45:41 +0100") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrledtgdduiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledruddtjedrvdeggeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrddutdejrddvgeegpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtoheprhhuuggrlhhitghssehgmhigrdgrthenucevlhhushhtvghrufhiiigvpedt X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:152328 Archived-At: >> Regarding TAGS, I spend much time killing TAGS buffers, but they >> quickly reappear in the buffer list like in a whac-a-mole type of game. >> Shouldn't such internal types of buffers be named with a leading space >> in their buffer names? > > Etags files are called TAGS and we usually set the buffer name from > the name of the file it's visiting. We should be able to prepend a > space but I have no idea where and when we visit the TAGS file. This is easy to fix, but I'm not sure if this might break some packages that depend on TAGS buffers with original names. >>> I'd rather restart with a buffer from the window-local list >>> provided that list is "long enough". That's fuzzy to implement. >> >> You mean a cyclic window-local buffer list? > > If it's long enough, yes. Note also that once a member of the global > list has been taken it will pollute the local list forever thus also > needlessly increasing the list of previous buffers for a window. > > More precisely, the problem is that of "navigational security" > (alternating 'switch-to-prev-buffer' and 'switch-to-next-buffer' calls > should reliably reproduce the buffer previously shown in a window to > avoid violating the principle of least surprise) vs "minimum > annoyance" (that of not switching to a buffer a user expressly doesn't > want to see). > > So I think that while the solution is to not allow > 'switch-to-prev-buffer' to switch to such an unwanted buffer, we > should allow 'switch-to-next-buffer' to switch to it. But I haven't > yet thought about all the implications. > > Also I'm not sure whether we should maintain for each window separate > lists of buffers we do not want to switch to but we might want to > consult in 'display-buffer-in-previous-window' or to leave such > buffers in the windows' lists of previous buffers and have > 'switch-to-prev-buffer' skip such buffers with the help of some > predicate. The latter would be more likely the way to go because we > then could allow a simple user option to provide that predicate. Maybe better to represent a list of prev/next buffers as a tree? Then inserting a new buffer inside it will create a leaf that can be ignored for navigation. An analogy of this is undo-tree.