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

From: Juri Linkov <[email-masked]>
Date: Fri, 16 Nov 2018 00:59:59 +0200

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

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.

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

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

I tried t mistakenly.  I intended to try 'pop' that works ok.

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

Another reason would be to force pop-up from switch-buffer, but
it's not the right thing to do.