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

[martin rudalics <rudalics@gmx.at>]

 >>>> 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