GNU bug report logs - #70784
Abolish string resizing

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: mattias.engdegard <at> gmail.com, 70784 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#70784: Abolish string resizing
Date: Tue, 07 May 2024 14:19:40 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: mattias.engdegard <at> gmail.com,  70784 <at> debbugs.gnu.org,
>   monnier <at> iro.umontreal.ca
> Date: Mon, 06 May 2024 20:23:16 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > We are not going to abandon backward-compatibility considerations.
> > But refusing to discuss significant changes just because they have
> > compatibility issues is throwing the proverbial baby with the
> > bathwater.  Refusing changes is of course 110% backward-compatible,
> > but it has many disadvantages, to say the least.  Instead, we should
> > see how to keep compatibility, to the extent that we consider it
> > important, without blocking changes which could potentially help us
> > adopting new technologies and improving performance.
> 
> These principles are no doubt valid in general, but please consider what
> is the feature whose continued existence is being called into question!
> `(aset string n foo)' has been possible and countenanced for ages

Which is why this is not the feature that was suggested to be
abolished.  Please leave strawmen and red herrings out of this
discussion.  No one in their right mind will agree to removal of
'aset' for strings in general.

> the performance of strings has never been a source of user
> complaint.

You are very wrong.  String performance in Emacs is a known problem,
as evidenced by the fact that we recommend that Lisp programs use
buffers in preference to strings.

I'm not saying that going with this proposal will necessarily make the
problem less severe, just that your over-reaching argument is patently
incorrect.

> Without such a plain justification and a clear strategy for evaluating
> whether the results so produced meet expectations, there really is no
> detriment in categorically dismissing proposals to alter them, until
> such time, if ever, as these conditions are created.

No one said that we will accept this change based on performance
considerations without seeing some performance data.

Previous Next

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