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 16:27:08 -0700 (PDT) Message-ID: 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> <56bae185-9309-43f1-9727-11e89080cd12@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="71670"; 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 Sun Jun 07 01:27:56 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 1jhiEG-000IYk-9c for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Jun 2020 01:27:56 +0200 Original-Received: from localhost ([::1]:34566 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhiEF-0006pd-Cg for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 19:27:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36688) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhiDk-0006N4-Jt for emacs-devel@gnu.org; Sat, 06 Jun 2020 19:27:24 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:42678) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhiDj-0006FZ-61 for emacs-devel@gnu.org; Sat, 06 Jun 2020 19:27:24 -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 056NMTBr121768; Sat, 6 Jun 2020 23:27:18 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=+BqNHSLyvrluksCaaKoppxP3zAelxE6E7VXBoLWXvCA=; b=aQmHrJ0ZJ9okj2ZLGIebk4tthXo2fmrcGrplBRG2PAH3BzYhtKvHVvnCw401qyrdDpCE AJPmRYL6Kp3e18nyrr4G0SBE7jQXvOZyEzzRTFAB5X2BegT9GvEcjZJwSj1NJyvL436G S3u3ZPQZp1hPqxPm71hiNwSOhLF/ai8UJ7AxhL4yPwfDcu5c69wlQgGsh/QvsLWCUfqb SGN4kOYJBztHZ8MWCsml5T6btgBJLz5D7JYb8a62WGP2h47RYTMe7u0Td0NTv9DB4Hyb yqWT3RfOWnvc/0+3OmRgXna/l8kUmTUtzYq9aCkH6cJQIGg6Du8C4fy5wvFGw+6HYu2A 6A== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 31g2jqt1mj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 06 Jun 2020 23:27:18 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 056NIBh6186046; Sat, 6 Jun 2020 23:27:18 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 31g2y3a7at-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 06 Jun 2020 23:27:18 +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 056NRCQh030077; Sat, 6 Jun 2020 23:27:12 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 phishscore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 spamscore=0 malwarescore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006060188 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-2006060188 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 19:27:21 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:251979 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. >=20 > I find it very hard to believe. Me too. But that's my current vision, and I'm stickin to it, until I see some good arguments to the contrary. Show me why we need (ever) to treat Elisp strings as immutable, at least wrt their text properties. > Either you're misunderstanding what we're talking about, or you do have > some really off programming habits. >=20 > Could you show some examples of code that rely of that "wonderful > feature"? Extra points if such code is available in an existing > Elisp package. I don't have an example. I don't have any such habit. And we don't yet have consistently, clean mutable literal strings. Show me that we couldn't. Elisp strings can have properties. You don't see the properties when looking at code. Neither does the Lisp reader etc. I don't see why we would think of strings appearing in Elisp code, i.e., literals, the way we think of them in C, as fixed things, constant. It's natural that a programmer might think that way. But I don't see why it's important to the Elisp language that we treat them that way. Please explain why it is. What's lost by treating them the same way we treat a value returned by `make-string' or `copy-sequence'? The `make-text-button' example is maybe a good example of why we shouldn't need to bother to constantize them. Dunno; I didn't really follow that discussion. TBH, I haven't thought about this before this discussion. But I'm wondering now why we ever try to treat Elisp strings as constants - wrt their properties, at least - rather than as mutable objects. Sure, it's unusual to think this way. But it's pretty unusual for a language to have propertized strings in the first place. The case of strings is different from both conses and symbols (with their properties), admittedly. And?