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

Previous Next

Full log

Message #116 received at 20489 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 20489 <at> debbugs.gnu.org
Subject: Re: 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: 20489 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 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.

Previous Next

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