GNU bug report logs - #40919
27.0.91; next-error-select-buffer does not always behave as documented

Previous Next

Package: emacs;

Reported by: Trevor Spiteri <tspiteri <at> ieee.org>

Date: Tue, 28 Apr 2020 01:52:01 UTC

Severity: normal

Found in version 27.0.91

Fixed in version 27.1

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 40919 <at> debbugs.gnu.org, tspiteri <at> ieee.org
Subject: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented
Date: Mon, 15 Jun 2020 02:15:30 +0300
>>> what kind of functions do they want to put on there?
>> Both next-error-buffer-on-selected-frame and
>> next-error-no-navigation-try-current.
>>
>>> And/or would they be content to advice-add on
>>> next-error-find-buffer-function instead?
>> Is it possible to add advice-add by using customization?
>
> No, or at least not yet. But if we know of only one user that wants this
> setup, surely that's not a problem?

It's a general problem that hindered the development of other features
that might benefit from customizable advice-add (namely set-multi-message).

> By the way, you were going to evaluate the new default. Do you now think
> that it's problematic somehow (and, for instance, the previous was a 
> better default), or do you want to change it as a purely
> personal preference?

Only personal preference, it seems the default in master is fine
for most users.

>>>>       ;; 2. If next-error-last-buffer is an acceptable buffer, use that.
>>>>       (if (and next-error-last-buffer
>>>>                (next-error-buffer-p next-error-last-buffer avoid-current
>>>
>>> Should we take the rest of the cases in next-error-find-buffer and move
>>> them to the default value of the above hook?
>> I don't think so, I don't believe someone might want to customize the
>> rest of the cases.
>
> Well, if you're sure about that.
>
> Having them all on the hook seemed logical to me, but indeed I don't know
> how necessary that is.

The reason why I think no one might want to customize the rest of the cases
is because I believe that next-error-last-buffer is always non-nil, so
all other cases (i.e. 3, 4, 5, 6) are useless and never used.  Isn't it so?




This bug report was last modified 5 years and 49 days ago.

Previous Next


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