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#33258: inhibit-select-window Date: Mon, 05 Nov 2018 10:34:17 +0100 Message-ID: <5BE00E99.1020003@gmx.at> References: <87muqpj8ib.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 1541410421 22227 195.159.176.226 (5 Nov 2018 09:33:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 5 Nov 2018 09:33:41 +0000 (UTC) To: Juri Linkov , 33258@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 05 10:33:37 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 1gJbGK-0005gD-3S for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Nov 2018 10:33:36 +0100 Original-Received: from localhost ([::1]:34151 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJbIQ-0005y8-Ls for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Nov 2018 04:35:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJbHy-0005j7-0H for bug-gnu-emacs@gnu.org; Mon, 05 Nov 2018 04:35:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJbHl-0006Rz-0c for bug-gnu-emacs@gnu.org; Mon, 05 Nov 2018 04:35:15 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58561) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gJbHk-0006I8-6V for bug-gnu-emacs@gnu.org; Mon, 05 Nov 2018 04:35:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gJbHj-0001Dj-GQ for bug-gnu-emacs@gnu.org; Mon, 05 Nov 2018 04:35:03 -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, 05 Nov 2018 09:35:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33258 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33258-submit@debbugs.gnu.org id=B33258.15414104684620 (code B ref 33258); Mon, 05 Nov 2018 09:35:03 +0000 Original-Received: (at 33258) by debbugs.gnu.org; 5 Nov 2018 09:34:28 +0000 Original-Received: from localhost ([127.0.0.1]:34582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJbHA-0001CS-E6 for submit@debbugs.gnu.org; Mon, 05 Nov 2018 04:34:28 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:49577) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJbH9-0001CG-2d for 33258@debbugs.gnu.org; Mon, 05 Nov 2018 04:34:27 -0500 Original-Received: from [192.168.1.101] ([46.125.250.97]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MN604-1gQCyQ1O7E-006hPb; Mon, 05 Nov 2018 10:34:18 +0100 Original-Received: from [192.168.1.101] ([46.125.250.97]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MN604-1gQCyQ1O7E-006hPb; Mon, 05 Nov 2018 10:34:18 +0100 In-Reply-To: <87muqpj8ib.fsf@mail.linkov.net> X-Provags-ID: V03:K1:QcRgEM83j1V8CxfBXaQgdRfT8+ZoxElc8KJXptFm5Vjx6PfspsF chXG2bP+7AzoekLHj7NrbKZ4lsmxpF1H3hriVxD7rFHpJWHaAtppBRFV6acrvjG+/v0eqEq QZMBW85/BEv0ufsHYYPC/NH5kQRQCrQCDZGAiNdkiaJqW0pktfcfwF5XCCTsn0E8L0R7eOI kp1JY0NpRXetBd4TBEP/w== X-UI-Out-Filterresults: notjunk:1;V01:K0:eD5eMYQ2iwA=:rWKOSfQ4u52ZTcx0XoGwLv sruPUEHO4ELi0feWFwmtIQcLEOxiC9wer7i7ChPyU9gYHgX4fjY6jYlFYvriSITbRy/1dZ4Ul AYV/b0YrJuFeuciTFwW/1eN0TUOPPW2oiM2f02I7V3rUQ2NWQC2qy4jCLqBCrGWwa8OrPGf4u X9WKJOQbqjaRZt+JYf/tI66pGT7bIK1I7EBwRdeejaNpW7g2i2yeCTYUcL6ObTyF8/t8MK1be /Egm2i7Zu+6HVpOprEHKs9ARAx4l9HWxhdhsCXZ3tqEWL3mmHi8HpjwPqHwtsGN4U3ptQalb3 GnolHS05NJmjZUNenc1NCF/aJ3gFNAQ90/GCWoviNlvbUTbozJyAwFprrCoCXxywAFAsQZ/7x wY6ETH9lh1ZGs86GbStWa/CKChacg/nOBHXqKpRmAIhyGJxFCu2IpBj/mo0l8e4bt5wS7ndxO py0Ku/MOpGr5T7dhn0QPJ7LO6tUs6SqJO0KCVIPVdEDsirlk3ceQiGRxGiz30GhsokjayarYD 8hZJirUXRgD4w8Pai9tZWRZQmdaQN9DpB/b3Z7R3FYYQvSChh2/f/U/iD7yEhmaDRP+TX/9GN Xq4Jrjur52LQ0zyTwgVvAhouXL5gvZbE5XbmcWhdi1qBckckJXSCL1aj3FfCmy6hI9pVAkMrw WEpd8LUjP85dythf6ffoCGaaCoZEuofp48BaFg1DxV6ORO/oYX7imHZGL83udO04auQ5CdBaq /9BJwxot6HIS2/m62vSMBoKRA6hutaQ8YUYF1voa0hLt8+xztSl24vBXSlq7SqfFXmf+3gah 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:152046 Archived-At: > Many commands use pop-to-buffer to display a buffer and > select its window by default. > > Sometimes it's not desirable to select the displayed window. > > One of the many examples is 'C-x v =' (vc-diff) where > the need is only to look at the diffs, but not to operate > on the *vc-diff* buffer in its window. Is this particular behavior caused by the ;; Display the buffer, but at the end because it can change point. (pop-to-buffer (current-buffer)) in 'vc-diff-internal'? > Currently there is no configurable way for the user > to override the default window selection. > > I propose a new alist entry to support such feature. > An example of usage in user's customization: > > (push '("\\*vc-diff\\*" nil > (inhibit-select-window . t)) > display-buffer-alist) > > then pop-to-buffer could check for the alist entry > 'inhibit-select-window' and to not select the window > if it's non-nil. I understand what you want but I doubt we can put that into practice. While not selecting the window might not be a great issue, not making its buffer current is. We would have to check each and every call of 'pop-to-buffer' as to whether subsequent code relies on the fact that it made the buffer current. This is not fathomable IMO. One could argue that 'display-buffer' may fail to produce a window and so the buffer would not be made current in that case either but as we know it is really hard to make 'display-buffer' fail. > OTOH, when a command uses display-buffer that doesn't select a window, > then the same alist entry with a different value or a new entry e.g. > '(select-window . t)' could be used to force selecting the window. > This could be implemented by using the same code from pop-to-buffer > and adding it to display-buffer functions. This would be possible. Such an entry would have to be called something like 'force-select-window' and could be applied by both users and programs for one soberingly simple reason: A Lisp program can never rely upon 'display-buffer' to _not_ select the chosen window - popping up a new frame may implicitly select the window at any time. martin