bug#28645: Status: 26.0.50; semantic-ia-fast-jump jumps to a random place in buffer

[martin rudalics]

> I would also be grateful for a little bit of background information. At
> which point did it become necessary to use 'pop-to-buffer' instead of
> 'switch-to-buffer'? Apparently 'semantic-ia-fast-jump' et al worked fine
> in older emacs versions.
>
> When is it ok to use 'switch-to-buffer'? There are numerous occurences
> of it throughout emacs...

Consider the following scenario:

(1) ‘switch-to-buffer-preserve-window-point’ is t (it is so by default).

(2) An application explicitly sets point in a buffer that is currently
    not displayed in the selected window to a value different from the
    value of ‘window-point’ of that window at the last time this buffer
    was displayed there.

(3) The application wants to switch to the buffer in the selected window
    with ‘window-point’ at the position of point assigned in (2).

If the application used ‘switch-to-buffer’ in (3), then ‘window-point’
will be reset to the old location of ‘window-point’ which is obviously
not what the application wants.  So to get what it wants, an application
either has to bind ‘switch-to-buffer-preserve-window-point’ to nil
around the ‘switch-to-buffer’ call or use ‘pop-to-buffer-same-window’
(‘display-buffer-same-window’ if the window may remain unselected)
instead.

IMHO applications should never call ‘switch-to-buffer’.  They should
either call ‘pop-to-buffer’ - if the user is supposed to now continue
working in the window showing the buffer - and ‘display-buffer’ in all
other cases.  Both allow the user to control how to display the buffer.

Only if there is a clear preference that the buffer should be shown in
the _selected_ window, the ‘-same-window’ functions should be called.
And programmers should be aware that at the time they want to show a
buffer in the selected window, that window might be the minibuffer
window or a window dedicated to some other buffer.

martin