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

[martin rudalics]

> Whereas I meant mostly switch-to-buffer as a command bound to 'C-x b',
> non-interactive calls of 'switch-to-buffer' have the same problem, and
> maybe some of them could be replaced with 'pop-to-buffer-same-window'
> without side effects.  One example is 'C-h C-n' (view-emacs-news) that
> uses switch-to-buffer, and can't be forced into another window.
>
> I solved this general problem for myself with such advice:
>
> (advice-add 'switch-to-buffer :around
>              (lambda (orig-fun &rest args)
>                (let ((buffer (apply orig-fun args))
>                      (window (selected-window)))
>                  (switch-to-prev-buffer window)
>                  (pop-to-buffer-same-window buffer))))
>
> Then 'S-M-right C-h C-n' shows it in the right window.

I don't grok it yet.  What's the 'switch-to-prev-buffer' call for?

> Do you think it's possible to add a corresponding customizable option
> that would provide the same behavior?

I would have to understand the "behavior" first.  One approach would
be to move the user-error and 'switch-to-buffer-preserve-window-point'
handling into the interactive specification handling and for the rest
do what 'pop-to-buffer-same-window' does.

>> 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?
>
> Another reason would be to force pop-up from switch-buffer, but
> it's not the right thing to do.

Something like "I never want to show another buffer in this window,
please remind me if I accidentally try to do that".

martin