[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-displ
From: |
martin rudalics |
Subject: |
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
- bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select, Ergus, 2021/06/16
- bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select, Juri Linkov, 2021/06/16
- bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select, Ergus, 2021/06/16
- bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select, Juri Linkov, 2021/06/16
- bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select,
martin rudalics <=
- bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select, Juri Linkov, 2021/06/17
- bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select, martin rudalics, 2021/06/18
- bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select, Juri Linkov, 2021/06/18
- bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select, martin rudalics, 2021/06/20