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

From: Juri Linkov <juri <at> linkov.net>
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: Wed, 07 Mar 2018 23:11:49 +0200
>>>> 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)
>>
>> But isn't it possible to do this in next-error-hook?
>> It's called by run-hooks in the same place in next-error.
>
> For one thing, next-error-select-buffer doesn't call next-error-hook.
>
> And there are other such places (e.g. like you were saying
> xref--xref-buffer-mode should set next-error-last-buffer similarly).

3. And hooks are intended only for user customization.

> Aside from that, why would we want to obscure this piece of logic behind
> a hook?

Instead of a hook I think it would be fine to define an “advisable” function
like Stefan asked to do for next-error-find-buffer-function to be able
to put advices on it.




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.