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 #184 received at 20489 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
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: Fri, 2 Mar 2018 03:19:01 +0200
On 2/28/18 11:17 PM, Juri Linkov wrote:
>> Anyway, I've fixed the current problem (see below), so this is a matter of
>> opinion. If you still consider this feature to be important, I think
>> ideally we'd abstract it away behind a new -function variable as well.
> 
> Please clarify what do you have in mind.  In what place in code such
> function could be called?

Any place that contains

  (setq next-error-last-buffer buffer)
  (setq-default next-error-last-buffer buffer)

now, would instead call

  (funcall next-error-save-last-buffer-function target-buf target-win)

>> This way, someone would also be able to implement window-local navigation
>> relationship instead of buffer-local (you've mentioned this option before).
> 
> Window-local navigation could be implemented by something like below.
> But maybe window-local specific code in next-error and next-error-internal
> could be abstracted away in a function that you proposed above?

Yes.

next-error-save-last-buffer-function and next-error-find-buffer-function 
would have to be in sync (we'd have to somehow make sure the user will 
have to try hard to set them to incompatible values, at least if they do 
that via the Customize interface).

Further, I think next-error-find-buffer-function will also have to 
encompass the item 2 in next-error-find-buffer, so that the alternative 
could supply the window-local value instead.

Anyway, I'd really like to put a pin in both buffer-local and 
window-local values for now, because they both complicate the picture.

Instead, could we address bug#30674 first? Personally, moving between 
errors and warnings in the current file using next/previous-error feels 
a lot more useful.




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.