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

[Dmitry Gutov]

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. After all, xref--next-error-function does move point, 
and that doesn't help (probably because it's called inside 
with-current-buffer, see next-error-internal).

Wrapping xref--next-error-function's definition in

  (with-selected-window (get-buffer-window xref-buffer-name)
   ...)

does help, but that seems silly.

>  . I see the places I visited marked by a special face in *xref*
>    (good!), but I don't quite understand when they get marked.

No special face, these are just unadorned buffer-substring values: the 
ones that have faces applied, are from buffer areas that had been 
touched by font-lock, the others hadn't. We could remove faces from all 
lines for consistency, but seeing them on at least some results is nice.

> They
>    certainly don't get marked as I move through hits with next-error
>    or with an explicit RET on a hit in the *xref* buffer.  Perhaps we
>    should mark them in real time?

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?

Having match-xrefs use a distinct structure from "normal" xrefs seems 
appropriate, but to fully go this way, I think we'll need the 
find-buffer-delayed feature first 
(http://lists.gnu.org/archive/html/emacs-devel/2015-08/msg00060.html). 
Because then we couldn't afford to have the location buffers closed (or 
reopen them all) when the xref buffer is rendered.