[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer wi

From: Dmitry Gutov
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

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.

   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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]