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

[Dmitry Gutov]

On 2/28/18 5:28 PM, Eli Zaretskii wrote:

> > > branch: master
> > > commit 108ce84432d597f92637ea74bd0a094224d157de
> > > Author: Dmitry Gutov <address@hidden>
> > > Commit: Dmitry Gutov <address@hidden>
> > >
> > >       xref--next-error-function: Move xref's window point
> > >       
> > >       * lisp/progmodes/xref.el (xref--next-error-function): Move
> > >       xref's window point if it's visible.  When we don't do that,
> > >       navigation can start looping after a while.
>
> 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.

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.