bug#32790: 27.0.50; point jumps unexpectedly after delete-window

[martin rudalics]

>>>> I'd invert these: The "-display-" infix implies that the buffer is
>>>> displayed and not popped to.
>>>
>>> Then easier just to rename it to windmove-pop-in-direction
>>> because most commands use pop-to-buffer, so this should be
>>> the default.
>>
>> That would be much better.
>
> The name 'windmove-display-in-direction' is more intuitive and still
> correct because it displays.  Select/no-select is a minor detail
> that depends on the prefix arg and a variable that I propose to name
> windmove-display-select.

OK.  We can easily add the "other" one later if there's a need.

>>> But currently I'm more concerned about inability to use switch-to-buffer,
>>> i.e. trying to display a buffer in another window with ‘S-M-down C-x b RET’
>>> doesn't work.
>>
>> You mean wherever we can't use 'pop-to-buffer-same-window' instead?
>
> Yes, and 'switch-to-buffer' should not use 'pop-to-buffer-same-window'.

You mean uses of 'switch-to-buffer' in code that we cannot (or are too
lazy to) replace with 'pop-to-buffer-same-window'.  Right?  Because
ideally code should not use 'switch-to-buffer' - we had quite a number
of reports that the point restoring mechanism conflicted with the
purpose to show a preselected buffer position in the selected window.

> I tried to set switch-to-buffer-in-dedicated-window to t instead of 'pop'.

I miss you here: Above you say that you want to display the buffer in
another window.  But setting 'switch-to-buffer-in-dedicated-window' to
t is useful only when you insisit on using the selected window.

> But I see now it's not worth the trouble to handle dedicatedness in
> 'windmove-display-in-direction' because it's not a general solution.

Windows have been often made dedicated so they get auto-deleted as
soon as their buffer gets buried or killed.  This use-case should now
be handled by the 'quit-restore' parameter.  I have no idea whether
windows are made dedicated for any other reason.  Do you?

In either case we can easily add an action alist entry telling
'display-buffer' whether to reuse an arbitrary dedicated window.

> Maybe simpler to rebind 'C-x b' from 'switch-to-buffer' to the command
> 'pop-to-buffer'?  Is 'pop-to-buffer' equivalent to 'switch-to-buffer'
> as a command with only difference in select/no-select behavior?

'pop-to-buffer' does not try to restore the previous position of point
in the chosen window.

martin