[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: |
Juri Linkov |
Subject: |
bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select |
Date: |
Thu, 17 Jun 2021 22:54:48 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) |
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?
- 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, 2021/06/17
- bug#49057: 28.0.50; windmove-display-in-direction ignores windmove-display-no-select,
Juri Linkov <=
- 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