From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select Date: Thu, 17 Jun 2021 22:54:48 +0300 Organization: LINKOV.NET Message-ID: <87sg1gp8qf.fsf@mail.linkov.net> References: <20210616064248.mqqzlt7qyxwqrcfy.ref@Ergus> <20210616064248.mqqzlt7qyxwqrcfy@Ergus> <87fsxitdmt.fsf@mail.linkov.net> <20210616121632.k365bes37rs5m6sl@Ergus> <87mtrpjtkm.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11702"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: 49057@debbugs.gnu.org, Ergus To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 17 22:00:50 2021 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 1ltyC2-0002w0-GP for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 17 Jun 2021 22:00:50 +0200 Original-Received: from localhost ([::1]:37574 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ltyC1-00039R-Go for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 17 Jun 2021 16:00:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38956) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lty8M-0004vu-NB for bug-gnu-emacs@gnu.org; Thu, 17 Jun 2021 15:57:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43648) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lty8M-0007Qb-DP for bug-gnu-emacs@gnu.org; Thu, 17 Jun 2021 15:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lty8M-0004mL-8e for bug-gnu-emacs@gnu.org; Thu, 17 Jun 2021 15:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Jun 2021 19:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49057 X-GNU-PR-Package: emacs Original-Received: via spool by 49057-submit@debbugs.gnu.org id=B49057.162395976518295 (code B ref 49057); Thu, 17 Jun 2021 19:57:02 +0000 Original-Received: (at 49057) by debbugs.gnu.org; 17 Jun 2021 19:56:05 +0000 Original-Received: from localhost ([127.0.0.1]:55192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lty7R-0004l0-6Q for submit@debbugs.gnu.org; Thu, 17 Jun 2021 15:56:05 -0400 Original-Received: from relay1-d.mail.gandi.net ([217.70.183.193]:3581) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lty7O-0004kP-9J; Thu, 17 Jun 2021 15:56:03 -0400 Original-Received: (Authenticated sender: juri@linkov.net) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id AD453240004; Thu, 17 Jun 2021 19:55:54 +0000 (UTC) In-Reply-To: (martin rudalics's message of "Thu, 17 Jun 2021 10:33:16 +0200") 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" Xref: news.gmane.io gmane.emacs.bugs:208677 Archived-At: tags 49057 fixed thanks > Conceptually, `pop-to-buffer' has to > > Display buffer specified by BUFFER-OR-NAME and select its window. > > so I cannot see anything wrong here. Step 5 must be allowed to override > any selection made in step 4 and any expectation derived from having set > `windmove-display-no-select' to t is moot here. I completely agree. All code that calls `pop-to-buffer' expects that `pop-to-buffer' will select the displayed window, so code could continue working on the selected window after its call. So the only safe solution is to select the needed window in post-command-hook, when the current command is already finished. This is how this bug is fixed now. > [BTW, `windmove-display-in-direction' is not a command but its doc-string > talks about > > If ‘windmove-display-no-select’ is non-nil, this command doesn’t > select the window with a displayed buffer, and the meaning of > the prefix argument is reversed. > > This should be fixed.] Now fixed as well. > Now we all know that `display-buffer' may or may not select the chosen > window. We cannot disallow it when the window shall appear on a new > frame because most WMs will "select" the new frame. Even trying to > disallow it in such case might be a bad idea because this instance of > `display-buffer' might have been triggered by a `pop-to-buffer' like > function and we will confuse the hell out of the WM - do not select the > new frame as `display-buffer' says, do select it as `pop-to-buffer' or > `switch-to-buffer' say ... > > So maybe we should relax that basic statement of `display-buffer' > > This command makes BUFFER-OR-NAME appear in some window, without > selecting the window or making the buffer current. > > because it is wrong anyway. Then we could add an additional action > alist entry, say 'select' with values like > > - t (try to select) > > - nil (avoid to select) > > and maybe `never' or 'on-new-frame-only' to emphasize whether > `display-buffer' is allowed to select the window and make its buffer > current. This has the advantage of freeing `display-buffer' from the > responsibility to decide whether it may select the chosen window. > > Then we could also try to use frame parameters like 'no-focus-on-map' > and 'no-accept-focus' right away and users do not have to specify them > explicitly via `pop-up-frame-parameters'. But wouldn't this be too confusing for users, when users will call `pop-to-buffer' with the new alist entry 'select', and it still will select the unintended window as `pop-to-buffer' currently does?