From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: `aset` on strings, changing the size in bytes Date: Sat, 08 Sep 2018 09:41:25 +0300 Message-ID: <83efe4trsa.fsf@gnu.org> References: <88must56x4.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1536388799 16001 195.159.176.226 (8 Sep 2018 06:39:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 8 Sep 2018 06:39:59 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, bojohan@gnu.org, emacs-devel@gnu.org To: Paul Eggert , Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 08 08:39:55 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fyWuR-00044v-0G for ged-emacs-devel@m.gmane.org; Sat, 08 Sep 2018 08:39:55 +0200 Original-Received: from localhost ([::1]:41510 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyWwX-0006t7-HL for ged-emacs-devel@m.gmane.org; Sat, 08 Sep 2018 02:42:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyWvw-0006rp-By for emacs-devel@gnu.org; Sat, 08 Sep 2018 02:41:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fyWvv-0001b6-JB for emacs-devel@gnu.org; Sat, 08 Sep 2018 02:41:28 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43511) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyWvr-0001Oa-Q1; Sat, 08 Sep 2018 02:41:23 -0400 Original-Received: from [176.228.60.248] (port=3385 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fyWvr-00037k-AE; Sat, 08 Sep 2018 02:41:23 -0400 In-reply-to: (message from Paul Eggert on Fri, 7 Sep 2018 16:12:07 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:229482 Archived-At: > From: Paul Eggert > Date: Fri, 7 Sep 2018 16:12:07 -0700 > Cc: emacs-devel@gnu.org > > Johan Bockgård wrote: > > According to the documentation, that is already an error... > > > > (info "(elisp) Modifying Strings") > > Cool! That means we can do Stefan's request simply by reverting Kenichi Handa's > patch that introduced the ability to change the byte length of a string (commit > 3c9de1afcde82a99137721436c822059cce79b5b dated 2000-07-21 06:45:30 UTC), since > that patch made the code explicitly disagree with the documentation. Though this > leaves open the question of why Handa made that change in the first place. What's the justification for such an incompatible change, though? This feature _is_ used, e.g. see ruler-mode.el. I understand that the effect of the change will be that whenever one wants to mutate a string by replacing a character, they would need to cons a new string, with the likes of (setq str (concat (substring str ...) new-char (substring str ...))) is that right? Which means in practice that 'aset' will need to generally disappear from string-processing code, because in practice it is impossible to know when the byte length will change without complicated calculations, so robust code will need to drop use of 'aset' for strings, except in a small set of specialized situations. Is that what we want? Or maybe the proposal is to modify 'aset' to do the above under the hood?