GNU bug report logs - #49057
28.0.50; windmove-display-in-direction ignores windmove-display-no-select

Previous Next

Package: emacs;

Reported by: Ergus <spacibba <at> aol.com>

Date: Wed, 16 Jun 2021 06:44:02 UTC

Severity: normal

Tags: fixed

Fixed in version 28.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


Message #17 received at 49057 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>, Ergus <spacibba <at> aol.com>
Cc: 49057 <at> debbugs.gnu.org
Subject: Re: bug#49057: 28.0.50; windmove-display-in-direction ignores
 windmove-display-no-select
Date: Thu, 17 Jun 2021 10:33:16 +0200
> 1. switch-to-buffer calls pop-to-buffer-same-window
> 2. pop-to-buffer-same-window calls pop-to-buffer
> 3. pop-to-buffer calls display-buffer
> 4. display-buffer calls display-buffer-override-next-command
>     that calls post-function from windmove-display-in-direction
>     that selects the old window
>
> 5. but later pop-to-buffer selects the new window,
>     thus overriding the specified selection of the old window.

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.

[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 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'.

martin





This bug report was last modified 3 years and 337 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.