[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: Eli Zaretskii
Subject: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason
Date: Mon, 29 Feb 2016 18:23:42 +0200

> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> 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

> 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.


reply via email to

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