From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: master f51f963: Fix some side-effecting uses of make-text-button Date: Sat, 6 Jun 2020 13:11:01 -0700 (PDT) Message-ID: <56bae185-9309-43f1-9727-11e89080cd12@default> References: <20200604223056.17078.81265@vcs0.savannah.gnu.org> <20200604223058.1850020A26@vcs0.savannah.gnu.org> <87eeqtiy4x.fsf@tcd.ie> <87img51y04.fsf@gmail.com> <5c66eeb5-a513-0443-4316-e41aae118677@cs.ucla.edu> <87img4zjy7.fsf@gmail.com> <1742051d-ff33-fe97-d0ee-83f55847d98a@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="71675"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Basil L. Contovounesios" , Stefan Monnier , emacs-devel@gnu.org To: Paul Eggert , Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 06 22:11:44 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jhfAN-000IXk-QK for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 22:11:43 +0200 Original-Received: from localhost ([::1]:59786 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhfAM-00061d-T6 for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 16:11:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46520) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhf9s-0005bz-Tg for emacs-devel@gnu.org; Sat, 06 Jun 2020 16:11:12 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:60744) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhf9r-0006kE-DM for emacs-devel@gnu.org; Sat, 06 Jun 2020 16:11:12 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 056K9G3h084642; Sat, 6 Jun 2020 20:11:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=7Ozl9d9iBQob3JaZrf/+0agX2VywvdHsF4DPEPHEbRc=; b=NpajN+HnYS/ydn7jrnYvAKPGZ+g+WCcyp8gGPKivofiwfuev/4/iAOa+uZ34rztanh+3 +aOE4pICqvO+1slcAFHYrfgc6/xitOcOheheIdZIcZ8f1tLlmXTwhds9f8K5dakyZ021 AFJ+wbLCDPXwSETGd9FVDeT7Stw1lxTywUNY35JRi85zSO+4GRvA891TSODHl9hMK1j7 Md8mZkNY6m4wYP6rn52WRy3mnMgi9W0o+KlYGQqBSiUGm6YGGv5cITYJrYNX8TYBxnWg sUCpkmyygzATb+E81xaGsPyHXvi9Ny/AYtQf/0EpU5v0ojEb9uuWksUDdqPBubE/21zH sQ== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 31g3smhpdw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 06 Jun 2020 20:11:08 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 056K7eIr034937; Sat, 6 Jun 2020 20:11:07 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 31g169ds8u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 06 Jun 2020 20:11:07 +0000 Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 056KB5Cr031016; Sat, 6 Jun 2020 20:11:05 GMT In-Reply-To: <1742051d-ff33-fe97-d0ee-83f55847d98a@cs.ucla.edu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5005.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9644 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 malwarescore=0 mlxscore=0 suspectscore=0 adultscore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006060161 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9644 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 cotscore=-2147483648 suspectscore=0 spamscore=0 bulkscore=0 malwarescore=0 phishscore=0 mlxscore=0 mlxlogscore=999 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006060161 Received-SPF: pass client-ip=156.151.31.85; envelope-from=drew.adams@oracle.com; helo=userp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/06 16:11:10 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251965 Archived-At: > It might be worth making such a significant change if > modifiable string literals were an important feature They are, IMHO. A wonderful feature. Other Lisps should be so lucky. > that Elisp programmers urgently needed. Urgently? As in an emergency? No. That's a pretty high bar. Do your proposed wholesale changes in the other direction handle an emergency? Urgent? > But they're not: they're rarely used, Evidence? But let's assume your guess is right. Is frequency of use really an important criterion here? List modification in Lisp is infrequent, but it's very important to Lisp - always has been, outside the use of "pure Lisp" for some research purposes. > partly because when they have been used their use > often caused subtle bugs (as we've seen with > make-text-button). That's because there are bugs in the implementation. And because there's not corresponding doc everywhere. The same thing is true of list-structure modification. (I hope your next crusade won't be to prevent that!) > They're not a feature worth fighting for, Your opposite "feature" isn't, IMO. > any more than mutable numbers would be. Wrong. An Elisp string is an object, with properties. When Elisp numbers get text properties your comparison might make some sense. > >> This will hurt performance a bit since it will > >> disable some optimizations. > > > > Which ones? >=20 > The ones Emacs is currently using, such as some strings are in read-only > shared memory, and some are coalesced. It would be unreasonable to coales= ce strings > if they were mutable, since that would mean changing one would change the= other. What's the cost in lost optimization? Any plan to fiddle with optimization should weigh the gain and loss. To you, there's apparently no loss, because you see no value in modifying string properties (or at least that's not important enough to keep - to "fight for"). > What I'm thinking of proposing ... is that Emacs signal > an error if a program attempts to change a string constant's > characters or text properties. Very not-good. What's next, impossibility to modify list structure? > That's a simple notion, It sure is. Too simple. And unlispy. > and it's something that Emacs long did for preloaded > strings so it's not like this would be a giant revolution. That some instances of a class of objects can be immutable is very different from denying all such objects the ability to change. Yes, that's a giant, and ill-conceived, revolution. > To my mind it's a considerably more-conservative > change than the one you're suggesting. "Conservative" or ultraconservative? It goes backward IMO, tossing out an important feature of Emacs Lisp.