Re: [Emacs-diffs] master 108ce84 2/2: xref--next-error-function: Move xref's window point

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 28 Feb 2018 17:58:59 +0200
> 
> > Sorry, this doesn't tell which problem(s) it attempts to fix, and
> > there are no references to discussions or bug reports that could help
> > me figure that out.  Without that, I cannot make up my mind about the
> > importance of this fix.
> 
> next-error can misbehave (resume from an earlier position) after several 
> invocations when next-error-last-buffer is an xref buffer, and that 
> buffer is visible.
> 
> Try:
> 
> 1. cd .../emacs/source/dir
> 2. emacs -Q
> 3. M-x project-find-regexp RET It is not necessary to RET
> (The searches for "It is not necessary to", which only occurs in .el files).
> 4. M-x next-error, do that a few times. Make sure *xref* is still 
> visible (otherwise, you need to tweak the split-threshold variables).
> 5. Select the window showing the xref buffer, then go back to where you 
> were (by typing 'C-x o' a couple of times).
> 6. M-x next-error will return to the beginning. Or, if the window point 
> of the xref window is not at the first line, start over from there.

Is this due to switch-to-buffer-preserve-window-point being t by
default now?

> The reason I figured it's urgent, is step 5 is not necessary with my 
> work configuration (not 'emacs -Q'). It's hard for me to tell now which 
> package/setting/timer has this effect, but it seems reasonable to 
> believe that some other users will see this too. Essentially, the code 
> in emacs-26 currently relies on "undefined behavior", in C terms.

I'm not sure I see where does "undefined behavior" come from.