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

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dgutov <at> yandex.ru>

Date: Sat, 2 May 2015 23:19:01 UTC

Severity: normal

Found in version 25.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


Message #110 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: Sat, 27 Feb 2016 12:14:07 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Mon, 22 Feb 2016 02:01:21 +0200
> 
> Now that the xref window is more "persistent", could you try 
> uncommenting the relevant lines in xref--xref-buffer-mode, and see if 
> the situation has improved here?

It looks much better now, thanks.  I think we can uncomment those
lines now.

A couple of minor nits:

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

 . I see the places I visited marked by a special face in *xref*
   (good!), but I don't quite understand when they get marked.  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?  That would also help in
   understanding what that face means, I think.





This bug report was last modified 7 years and 72 days ago.

Previous Next


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