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 09:57:23 -0700 (PDT) Message-ID: <170bedfa-7119-4d6a-9d4f-e94ba0f7cc2b@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="24031"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Basil L. Contovounesios" , Stefan Monnier , emacs-devel@gnu.org To: Pip Cet , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 06 20:24:42 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 1jhdUo-0006Ap-4Z for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 20:24:42 +0200 Original-Received: from localhost ([::1]:43506 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhdUn-0005Wh-7w for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 14:24:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56558) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhdUH-00052G-LP for emacs-devel@gnu.org; Sat, 06 Jun 2020 14:24:09 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:44240) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhdUF-00011U-T4 for emacs-devel@gnu.org; Sat, 06 Jun 2020 14:24:09 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 056Guuwl093945; Sat, 6 Jun 2020 16:57:39 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=wUPK3hR/4ZtrGMzu/ly3v654tj0ZOfbS9shPQbPSASA=; b=Y2Wu/wgT+/bqdYe2tifScxiMFP1bIWuLIeLQVUCsQhL9EiCHAAtif9pjNidVzxZ9sYrw jixbLTHQ/Set0nK2i3MtW+Hvzhe+jSKaRJCzCTPD0QgN1zj1vTFG/Qa/lgDrRXNqpnVt iVD6K87W7ceQd0EWACwxsdmrs6vV09mw4m8OjxJDtYcOkbTR/yHbPmQJMsBbiMMO3Ef3 +u/uhmykThaHJ6e52KriyuF6XefYR+CnyWO9WKUoBYbHqRSIbfZhgKI0hBqOjgCh4Pmn xtz2DFMP2CKT8QS8OK3s4vJ+W96bt2odoBITDcw93bBEI5As40+wln73V7RSo6TUdSUr Vg== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 31g33ksftc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 06 Jun 2020 16:57:39 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 056GsDnG052023; Sat, 6 Jun 2020 16:57:38 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 31g2fhf3kq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 06 Jun 2020 16:57:38 +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 056GvRZJ008970; Sat, 6 Jun 2020 16:57:27 GMT In-Reply-To: <87img4zjy7.fsf@gmail.com> 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 spamscore=0 suspectscore=0 adultscore=0 phishscore=0 mlxlogscore=999 malwarescore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006060134 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9644 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 spamscore=0 cotscore=-2147483648 malwarescore=0 phishscore=0 mlxscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 priorityscore=1501 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006060134 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/06 14:16:14 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:251958 Archived-At: > >> I get the impression we > >> shouldn't discount the possibility that the current way of doing thing= s > >> (after pure space) isn't so bad at all: all strings, vectors, and cons > >> cells are mutable to the same extent. > > > > That's not the current way of doing things, and although the area is > > murky there have always been Emacs Lisp objects that are not mutable. >=20 > Lately, only pure ones, as far as I can tell? >=20 > > For example: (aset (symbol-name 'cons) 0 ?d) > > This signals "Attempt to modify read-only object" error in Emacs 25, an= d > > makes Emacs dump core in Emacs 27. And there are other cases like that. >=20 > Well, dumping core is bad. The problem here is how pdumper "changed" > pure space (actually, we're putting several megabytes of zeroes into > every Emacs binary as a result) and how make_pure_c_string tries so very > hard to save a few kilobytes of memory. Both problems, as I said, that > wouldn't exist if we simply removed pure space. >=20 > > Obviously we need to do better in the dumping-core area. When we do tha= t, > > we have an opportunity to simplify and/or document behavior in this are= a. >=20 > Indeed. Simplify: remove pure space. Document: all strings, vectors, and > cons cells are mutable to the same extent. >=20 > > If we decide to simplify/document by saying "all strings are modifiable= " > > then we'll need significant work at both the C and Lisp level to do tha= t. >=20 > I don't see why. All strings are modifiable, but the byte compiler will > identify strings under certain circumstances. That doesn't violate the > simple rule that as far as the Emacs core is concerned, all strings are > equal. >=20 > > This will hurt performance a bit since it will disable some optimizatio= ns. >=20 > Which ones? >=20 > > If we decide to simplify/document by saying "an error is thrown if you = try > > to modify a string literal" then we'll need to add some code to do that= . I > > have a >=20 > So far, what you have proposed is "an error is thrown if you try to > modify the characters of a string literal, or if you add text > properties unless it already has some, or if you remove the last text > property". >=20 > > draft of something along those lines. It doesn't hurt performance > > significantly in my standard benchmark of 'make compile-always'. >=20 > (In general, I think that's probably not a good benchmark to optimize > Emacs for). >=20 > > Although it invalidates some existing code, such code is quite > > rare and is already relying on undefined behavior. >=20 > I'm not sure "undefined behavior" is a useful term when speaking about > Emacs Lisp, except for behavior which is explicitly documented to be > unreliable. There's a single implementation, and a lot of code is > written to conform not to what's documented but to what happens to > work. >=20 > > If we decide to leave things alone, they will remain complicated and mu= rky. >=20 > But I'd call the behavior you suggest even more complicated. Amen. > I still think there's a significant risk that there will be ad-hoc > changes that essentially commit us to a simplistic model of > mutability. I don't think they're necessary or urgent, except for the > make_pure_c_string bug you describe. >=20 > For example, I think it might be very useful to have an immutable "view" > of a mutable object (as in C, where I can pass a char * to a function > expecting a const char *); that would mean storing the mutability flag > in the Lisp_Object, not in the struct Lisp_String. +1. All that Pip says here makes sense to me, as far as I understand it. (I can't speak to the implementation matters, e.g. use of pure space.) If someone has the cycles and will to improve things by making the modification of strings, including what look like literal strings in code, easier and more flexible - in particular text properties, great. But going backwards, toward some perhaps unneeded optimization, in the direction of systematically raising an error when trying to modify text properties of a string, is not a good idea, IMO. Before even considering optimization there should be some analysis of what would be gained and what would be lost. Yes, currently there is some mess and uncertainty. But there are good and bad cures to mess and uncertainty - different kinds of "cleanup".