Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason

From: Eli Zaretskii <[email-masked]>
Date: Mon, 29 Feb 2016 18:23:42 +0200

> Cc: [email-masked]
> From: Dmitry Gutov <[email-masked]>
> Date: Mon, 29 Feb 2016 05:15:10 +0200
> 
> On 02/27/2016 12:14 PM, Eli Zaretskii wrote:
> 
> >  . When one uses next-error to step through hits found by Dired's 'A'
> >    command, point in the *xref* buffer doesn't move to the hit that is
> >    visited in the window displayed above *xref*.  Given how next-error
> >    works in other cases, I think users will expect point to move
> >    accordingly; at least I did.
> 
> It would be helpful, but it doesn't seem like `next-error' was designed 
> with this in mind.

Really?  Isn't that strange?  Doesn't every user of next-error want
that?

> Wrapping xref--next-error-function's definition in
> 
>    (with-selected-window (get-buffer-window xref-buffer-name)
>     ...)
> 
> does help, but that seems silly.

Right.  Too bad if this doesn't have an easy solution, but if so, I
guess we will have to live with that.

> Not sure how to introduce that feature into the API in a generic 
> fashion. Perhaps if we decided that the "summary" of each xref-match 
> instance is always defined by the buffer contents?

OK, then let's forget about this until the necessary infrastructure is
in place.

Please uncomment those lines, if you didn't already.

Thanks.