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

[Bastian Beischer <bastian.beischer@gmail.com>]

Hey Martin,

On Wed, Oct 4, 2017 at 11:03 AM, martin rudalics <rudalics@gmx.at> wrote:
>> 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.

I understand. Then this must mean that the change in behavior in CEDET
was triggered with this commit:

commit ee297210cffb9e8d05912686a39fa158414ba050
Author: Mark Oteiza <mvoteiza@udel.edu>
Date:   Thu May 26 21:47:18 2016 -0400

   Preserve buffer point in windows by default (Bug#4041).

   * doc/lispref/windows.texi: Mention new default.
   * etc/NEWS: Mention new default.
   * lisp/window.el (switch-to-buffer-preserve-window-point): Default to t.

which is part of master and emacs-26 but was not part of any previous releases.

I also understand your other arguments. But the question is: While
your recommendation makes sense, there clearly still is a lot of code
which uses switch-to-buffer without binding
switch-to-buffer-preserve-window-point to nil and it wasn't fixed when
this variable's default was changed. This is true in lisp code shipped
in emacs and it is probably also true for lots of third party code in
the wild. Who is going to fix all this code? And if it turns out that
the fixing all this code is too difficult / impossible, is it
justified to fix bug #4041 at the cost of causing numerous other bugs
(which arguably are due to misuse of switch-to-buffer, but they will
have to be fixed either way)?

>
> martin
>

Cheers and thanks again for your answer.
Bastian