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:19:07 -0700 (PDT) Message-ID: <68198d80-34f2-4f06-b964-9157f4d43c9e@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> <170bedfa-7119-4d6a-9d4f-e94ba0f7cc2b@default> 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="106337"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Basil L. Contovounesios" , Paul Eggert , Pip Cet , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 06 22:20:06 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 1jhfIU-000RaC-8t for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 22:20:06 +0200 Original-Received: from localhost ([::1]:39212 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhfIT-0001LW-B7 for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 16:20:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47396) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhfHg-0000YQ-Uf for emacs-devel@gnu.org; Sat, 06 Jun 2020 16:19:16 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:45796) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhfHf-0008Ud-Ke for emacs-devel@gnu.org; Sat, 06 Jun 2020 16:19:16 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 056KIAGf064072; Sat, 6 Jun 2020 20:19:12 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=eRih6B0il1W9Jj8li/wEYNGTvuo20b7nBCVmEw3hN10=; b=QdPCYCrVLJJNit6FiMZ2GizS7UadkNyNPr/BPbw5N97Ci+XdtAwlj4bbyguln4Yg/cYg zxTUoe4xcQ+niPT1o0qyvHKjPehyjocTc9I/EYeoBkd0lDpMrUxPgJ8UrTqaSm879RN7 hG8syior/bmdHaP9pUlf6vvIaael+Q2ol41zWNcrA8Ji6/PiIE6bu7UvMYzdqkLof6ko VT4D9rpI5G2luLLknn6dHefbkV4GB3j8vWTHqF8fRx3LX5homL2SgYaMF4jLIh3JEwDf +pvUygJHV5oGkuJStQ/Av8uUKyHla+BPCKkDGfrTAultU8rxIYc8vLYtOUSd8Vh5igbE UA== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 31g2jqstgv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 06 Jun 2020 20:19:12 +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 056KIEYq068184; Sat, 6 Jun 2020 20:19:12 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 31g2fhm32c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 06 Jun 2020 20:19:11 +0000 Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 056KJAYr029128; Sat, 6 Jun 2020 20:19:10 GMT In-Reply-To: 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-2006060162 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9644 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 impostorscore=0 cotscore=-2147483648 priorityscore=1501 spamscore=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0 mlxscore=0 phishscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006060162 Received-SPF: pass client-ip=156.151.31.86; envelope-from=drew.adams@oracle.com; helo=userp2130.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/06 16:19: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:251968 Archived-At: > > 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. >=20 > I think there needs to be a clarification here: the issue is about > modifying data (here specifically strings, but the issue applies to all > other such data) that appears as literal in the code. Yes, I know. > This issue is not one of optimization (preventing those modifications > would likely impose a slowdown, if anything) but one of detecting usage > that is usually a bug (one that leads to people being utterly > confused by the resulting behavior). The resulting behavior now is undefined/unpredictable in the problematic cases. That's the problem. List-structure modification too can result in application bugs and confusion. That's not a reason, in Lisp, to prevent such modification. Lisp, including Elisp, gives you lots of rope to hang yourself with. A "literal" string occurrence in code is what the implementation of Emacs defines it to be. Strings can have text properties. Those are not visible as program text (code, viewed lexically). Maybe no strings in Elisp should really be considered "literal" in the usual sense. Unless some sophisticated analysis takes place, to determine that no modification of a given string's properties will/can/might take place, there are two "extreme" positions possible: 1. Disallow modification of a string's text props. 2. Allow modification of a string's text props. Something in between is also possible. We have something in between now, but it's unclear or undefined or accidental. As I understand it, Paul proposes extreme #1. I'm closer to extreme #2. But I say that any backtracking from #2, and especially any backtracking from what Emacs has had so far (ad hoc, accidental, partial, or what have you) - any considering a string ("literal" or not) as needing an error to be raised if an attempt is made to change its text properties (including adding some when there are none) is a loss. And any such loss needs to have a good supporting argument - as strong an argument as for raising an error for list-structure modification where today there's no such error-raising. Elisp programmers need to be able to do both: (1) program without structure modification (list, string, whatever), and (2) program using such modification. And the "literal" case really shouldn't, I think, be a special one. I think that now, even for a quoted list, but I won't argue that case. (A quoted list is clear just from the program text. A propertized string is not clear textually, in the general case.) I don't expect others to hold the same "extreme" position. But that's the direction I'm thinking in now, FWIW. And so far I haven't seen any good arguments in the other direction. We heard arguments about important "optimization". You've tossed that aside now, at least for literal strings, saying there's no such optimization and in fact there may be a performance cost. Your argument is instead the value in "detecting usage that is usually a bug (one that leads to people being utterly confused by the resulting behavior)". That needs to be shown. And not just by pointing to the current all-bets-are-off situation in terms of understanding. Please make the argument in terms of a situation where every string is considered to have modifiable text properties (extreme #2). When I see a good argument against #2, maybe I'll pull back from it a bit. ;-) Certainly, the general argument against this kind of thing _is_ in terms of (1) simplicity of program analysis and (2) performance. It's the argument of compilation vs interpretation, more or less. I'd argue that Emacs Lisp is, among all the Lisps, the one where use by end users of the result is the most important, and interpretation (vs compilation) is relatively more important than for other Lisps, and performance and static (lexical) analysis is relatively less important. (And that's from someone who wishes that Elisp would take more from Common Lisp, which is far from #2.)