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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 40919 <at> debbugs.gnu.org, tspiteri <at> ieee.org, juri <at> linkov.net
Subject: Re: bug#40919: 27.0.91;
 next-error-select-buffer does not always behave as documented
Date: Mon, 25 May 2020 18:17:58 +0300

> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Mon, 25 May 2020 04:58:05 +0300
> Cc: 40919 <at> debbugs.gnu.org, tspiteri <at> ieee.org
> 
> On 25.05.2020 00:48, Juri Linkov wrote:
> >>> Is this patch for master?  So there is enough time for thorough testing?
> >> I think it's for master. Though if we put it into emacs-27 and changed the
> >> default to the name of the new function, the behavior shouldn't change, and
> >> yet it would be easier to "fix" this bug through user
> >> configuration... (ʘ‿ʘ)
> > Yes, this will fix the reported problem of customizability.
> > Maybe Eli will agree to fix this in emacs-27.
> 
> I can post the corresponding patch, if it helps.

It's okay to add a defcustom and a new function, but the other part of
the patch changes the default behavior, and that is less okay.  Can we
do one without the other?

(Btw, the textual descriptions of the options both in the patch and
those already in the code are confusingly obscure, so much so that I
don't think I could understand what each one does.)

All in all, I feel (for quite some time) that this area is
over-engineered and keeps bumping into more and more unintended
consequences.  Maybe it's time to take a step back and rethink the
entire subject?  (But definitely not on the release branch.)

Previous Next

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