GNU bug report logs - #64391
30.0.50; buffer narrowing slowdown regression in emacs 29

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: acohen <at> ust.hk, 64391 <at> debbugs.gnu.org, gregory <at> heytings.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#64391: buffer narrowing slowdown regression in emacs 29
Date: Fri, 07 Jul 2023 21:22:01 +0300

> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Fri, 7 Jul 2023 18:49:56 +0200
> Cc: gregory <at> heytings.org,
>  acohen <at> ust.hk,
>  64391 <at> debbugs.gnu.org,
>  monnier <at> iro.umontreal.ca
> 
> 7 juli 2023 kl. 14.50 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> >>> I was considering applying only the first of Gregory's patches,
> >>> without the second.  WDYT?
> >> 
> >> I don't think that makes much sense -- the division between the two is pretty much artificial.
> > 
> > It makes sense to me, because it minimizes changes in the code, which
> > at this stage in the pretest is something very important, IMO.
> 
> Oh, I certainly appreciate the importance of conservatism in changes
> on the release branch, but sensibly so -- it's not a game of code
> golf. Only applying half of the intended change leaves the code in
> an ugly state,

Ugly is in the eyes of the beholder.  The release of Emacs 29 was
already delayed twice by this feature, so please forgive me if my
sense of aesthetics in this regard is beginning to fade.

> and does in fact not minimise risk at all, quite the opposite.

How so?  If the patch solves the problem, the problem is solved,
period.  Where's the risk in not applying unnecessary changes?

Previous Next

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