From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#32825: 27.0.50; Deterministic window management Date: Mon, 12 Nov 2018 09:45:41 +0100 Message-ID: <5BE93DB5.8070804@gmx.at> References: <874leeaiah.fsf@mail.linkov.net> <87y3adakkh.fsf@mail.linkov.net> <5BDAC0ED.9030405@gmx.at> <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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1542012864 18043 195.159.176.226 (12 Nov 2018 08:54:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Nov 2018 08:54:24 +0000 (UTC) Cc: Michael Heerdegen , 32825@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 12 09:54:20 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 1gM7z9-0004YE-6P for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Nov 2018 09:54:19 +0100 Original-Received: from localhost ([::1]:47065 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gM81F-0007mG-KT for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Nov 2018 03:56:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53532) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gM7yo-00064H-SK for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2018 03:54:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gM7r8-000198-IS for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2018 03:46:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42809) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gM7r7-00018Y-RQ for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2018 03:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gM7r7-0000j3-Ne for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2018 03:46:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Nov 2018 08:46:01 +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.15420123582780 (code B ref 32825); Mon, 12 Nov 2018 08:46:01 +0000 Original-Received: (at 32825) by debbugs.gnu.org; 12 Nov 2018 08:45:58 +0000 Original-Received: from localhost ([127.0.0.1]:47067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gM7r3-0000il-NX for submit@debbugs.gnu.org; Mon, 12 Nov 2018 03:45:57 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:48331) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gM7r1-0000iW-JF for 32825@debbugs.gnu.org; Mon, 12 Nov 2018 03:45:56 -0500 Original-Received: from [192.168.1.101] ([213.162.73.18]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M5Lmp-1fZ5412RAN-00zZRG; Mon, 12 Nov 2018 09:45:46 +0100 In-Reply-To: <87pnvbpejc.fsf@mail.linkov.net> X-Provags-ID: V03:K1:hpV9CDBh8t4NuKOq9X/ILJLA52eEETsN+2wt4j+rgmqGLJh5ng4 Xc35+EeXD505lXFsuW8NC4X1M/kk8qk9WemvpIkDVWmrIm1m/tiWNZLZNnU0AJVbmb4gVw3 NfUhWmdo6APUFCV24aIVGwjaRy7Qsf7ofNdY/NNb/y0bPuxCFHp2gPdpYEO3tblySNNZm2B SNpPhGPIY/eY6tzFCvbdA== X-UI-Out-Filterresults: notjunk:1;V01:K0:W94J3/4tI8c=:3L1sJX8f4n4LN37j2F7k+r eKiSBIxye1ZpJCA4Td5gWftz2Mm7HzfV2gxLn0E9uS0b7giJh+l3vjeydjkxHZjw6C1qyW8Ar +Ul8SzqOLQl9QZ7IVh+ZT9AJ/40BPh6tBovX+HYEed2E3lQrIWZioA1VdQX0Qkh8D+pxlhiZT n1l2/tTcR2KetTKwcp+YGrLIWlwEgln8W2QBzaHI1jJZ14Q+Ed0YoRYXFwnMGzA9u3HIPUXHb 89BRcuJq5AnSMMGtmfeMGaVE7YvL8UfFOsuc/68/5lnbTC7JC1N8dh9KVAUcai+82+hSELKhb EAil/hhIUgitYtSajAitguNICgujtlK6pifOzTV8jnifc4Mhoco0GibSvCuytRKVWs4rLf1MZ K38n+dvvEhEC9uKBdWwrN0kd0wMwzCuLfwi9q48eewQ85lj79Dz0h0LGxF8ehgE03dVWGuFlU yi9Q8MPh3kWMMXQixptzC62fNGI4wea2TG/zfj1ix2oGCpO9h5iXbEUQEs+1ilzz1A8qZhkQt pzy6RBi/FsgeMo8Rw0PhNZgK+qwmtRWGIwyTURXIqJTn8mnET/GMxPiAa7fyL/oKQZq40fh9h CdZeYb6Xov8Nf9IOIUShWdPZvzCxyQfnmW/dqu3uO0I6LoDBfx6HQdOe0Ks7ddpq+Kwqjy7PR AtsAatADMgwESCGQS6HOmnzns4SclGivP0u+nbWBli3Q8a96AratTPS2HIoLUrF9ci9Uz20qf M2cHI2YXg01ZswvrajugdFO1o4lGWi1HSArM+HUpkl3qG4Srs+bPuHoTB0wRKe0FBvHUPBv/ 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:152316 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. >> 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 the notion of burying should also apply to window-local > buffer list? So burying a buffer should push it to the end of > window-local buffer list? If 'switch-to-prev-buffer' didn't already do that it would be severely broken. martin