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: =?utf-8?B?UkU6IDMxMzk1NTExOiAiRG9u4oCZdCBhdHRlbXB0?= =?utf-8?B?IHRvIG1vZGlmeSBjb25zdGFudCBzdHJpbmdzIg==?= Date: Fri, 5 Jun 2020 10:01:08 -0700 (PDT) Message-ID: <636e4f34-aa10-4e3b-9d61-af6fa6e8d723@default> References: <871rmvn7ge.fsf@gmail.com> <87lfl36abx.fsf@gmail.com> <1abe5965-b48e-6dee-1516-c5c233f09d01@cs.ucla.edu> <87d06f5m2c.fsf@gmail.com> <87lfl3f5mj.fsf@tcd.ie> <87k10m4l5v.fsf@gmail.com> <8e691d13-8db0-2066-8725-ea8afab7c506@cs.ucla.edu> <94615cb2-9eda-7c1d-e55c-f89e007cac80@gmail.com> 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="106561"; mail-complaints-to="usenet@ciao.gmane.io" To: =?utf-8?B?Q2zDqW1lbnQgUGl0LUNsYXVkZWw=?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 05 19:05:58 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 1jhFn3-000RbN-PA for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Jun 2020 19:05:57 +0200 Original-Received: from localhost ([::1]:32838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhFn2-0007MP-RY for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Jun 2020 13:05:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42296) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhFiX-0007yj-Ks for emacs-devel@gnu.org; Fri, 05 Jun 2020 13:01:18 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:60206) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhFiW-0004FR-1l for emacs-devel@gnu.org; Fri, 05 Jun 2020 13:01:17 -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 055Gq7xV155886; Fri, 5 Jun 2020 17:01:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=+e6IYBeaVyMJaVqqmnNcdAj6jnVbmM//dCEc4k/bZFc=; b=FnleInTObniBAXIybCbcKyqbLDH6bd9qpiXQRcR8ZyBC7jDapo5ztdgrBLSqBg0ra5Nl dzWCVob94aMENQn8faEWsLQCmgT2dUk2m3CRhhBVLCjSHbyP4kk9EroL/n1pOtgL7KAN boQKDllStfUaumpGq8hyv9zkBOMHKvxEaPJ58QLaO6TZs9EQCNzXa8Roloenb7HS9xHU rmbB1DypV/ENncyrxGoZ9/hNn+lIBdFl23gZVAU4IioJRF0k+z+EBb6TcHYhNXjPcO5i T5nrtn26xgxFtJV0t5OOcV9l7gGsYVCimrJKvebBZ2GW+GP0yau2YkHqltBmHjtdh1WZ Lg== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 31f9243ux9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 05 Jun 2020 17:01:12 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 055GnQbJ147751; Fri, 5 Jun 2020 17:01:12 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 31f92t1nhr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Jun 2020 17:01:11 +0000 Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 055H1A3q022613; Fri, 5 Jun 2020 17:01:11 GMT In-Reply-To: <94615cb2-9eda-7c1d-e55c-f89e007cac80@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=9643 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 mlxscore=0 malwarescore=0 spamscore=0 suspectscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006050127 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9643 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 impostorscore=0 adultscore=0 priorityscore=1501 mlxlogscore=999 mlxscore=0 bulkscore=0 lowpriorityscore=0 cotscore=-2147483648 phishscore=0 spamscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006050127 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/05 13:01: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:251912 Archived-At: > > I don't think this matters much, since string > > literals shouldn't have text properties. >=20 > Really? I've used the reader syntax for propertized > strings a few times =E2=80=94 it's pretty convenient. +1. And not just using reader syntax, i.e., not just #("whatever" ...). =20 "String literals shouldn't have text properties" is an unhelpful and unlispy mantra. It, in effect, marginalizes the use of propertized strings. And to what end - what's the gain that offsets the loss? "String literals appearing in code shouldn't be implemented as constants" is a better mantra, if we need a blanket point of view - hopefully we don't. Privileging byte-compiler optimizations such as treating literal strings in code as constants, over Lisp flexibility, is counter-productive and not worth it. What's lost is greater than what's gained (presumably some space or speed). Just as a (global) symbol is an _object_, with properties, so can an Elisp string be. That's a powerful construct (missing in other Lisps). Expecting users to use `make-string' or some such, to avoid constant-string modification - a la using `cons' or `list' to avoid modifying constant list structure (e.g. quoted lists), isn't very lispy, helpful, or reasonable. This is true whether or not this has long been problematic (accidentally or intentionally). Users should be able to propertize a string written literally in code, and change the properties dynamically, over and over, without inviting trouble. They already know to use `copy-sequence' when they need to ensure a new string and not bother an existing one. That should be about all they ever need to do. We should favor use of Elisp by Emacs users. In general, we shouldn't toss out flexibility and convenience in an attempt to achieve general-programming language features such as high performance. It's OK to offer high performance if there's no cost in convenience or flexibility, or if that cost is really worth it. And it's OK to offer it optionally, where the sacrifice is an intentional trade-off (by a user). If you go the other way on this, then we at least need to provide a simple way to manipulate strings with properties - something simpler than fiddling with `make-string' and `copy-sequence' as often as we need to use `cons', `list', and their backquote-comma equivalents to avoid the gotcha of modifying a quoted list. If I use `copy-sequence' once, to ensure that I don't bother an existing string, I should be able to modify my new string over and over, especially its text properties. A quoted list that gets modified is bad enough as a gotcha. Many users never modify list structure, and the doc makes clear when some function does that. And we try to document that modify-quoted-list gotcha explicitly. Not perfect, but we do try to help users with that gotcha. Modifying _symbol_ properties isn't a problem because there is only ever one symbol with a given name interned in a given obarray, and the properties are separate from the obarray. The obarray just holds the symbol identifier. Modification of string properties needs to be dealt with and documented reasonably, somehow. Currently we can't rely on something like an obarray, as we do with symbols. And probably more users will modify string properties than list structure, so we need a solution that is at least as good as the way we handle the list gotcha. Modifying the _chars_ in a string might be a different story. It's string properties I'm mostly concerned about here. We should look for a reasonable solution that helps Emacs users, and not just favor compiled code performance. I know that more than the compiler is involved. There's also the reader. I'm asking for a solution that makes modifying string properties less, not more, problematic. And barring any advance in the direction I'm suggesting, let's at least try to give users good, clear doc about whatever gotchas do exist for modifying string text properties. That's not the best solution, but it's a necessary fallback if nothing is improved in this regard in the code. Just one opinion. +1 for propertized strings, a wonderful Emacs-Lisp feature.