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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20489 <at> debbugs.gnu.org
Subject: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason
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. 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.