From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: 31395511: =?utf-8?Q?=22Don=E2=80=99t?= attempt to modify constant strings" Date: Thu, 04 Jun 2020 20:43:08 +0000 Message-ID: <87k10m4l5v.fsf@gmail.com> 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> 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="38266"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: "Basil L. Contovounesios" , =?utf-8?B?Sm/Do28gVMOh?= =?utf-8?B?dm9yYQ==?= , emacs-devel To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 04 22:44:53 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 1jgwjM-0009oh-FS for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Jun 2020 22:44:52 +0200 Original-Received: from localhost ([::1]:48628 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgwjL-0004kT-Hh for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Jun 2020 16:44:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51478) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgwhq-0003Tc-7M for emacs-devel@gnu.org; Thu, 04 Jun 2020 16:43:18 -0400 Original-Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:35424) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jgwho-0001ZK-Oc for emacs-devel@gnu.org; Thu, 04 Jun 2020 16:43:17 -0400 Original-Received: by mail-wm1-x32c.google.com with SMTP id q25so7042869wmj.0 for ; Thu, 04 Jun 2020 13:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=Dr9pyVpWIz/Jd2ut7s7QHn+LJPfDxMdlERxwbqKyW28=; b=ogNLSdTSHIWp+J8O7LYvchxaA5aHHKWExrXqQdkKLkUnE5KKT3WBPFhPj1TADxQilq BwF8oMmqXeWv1Wekwtz2C3Bmi0JRINkZJIbTkh0BXr4eIEDE5vCmqlFcKDT2Oj8USR97 looDcylec1kk2lCTkJ3eT+UC53gJZFlteanYpr/GKGjp3AC0mxk0rBvciWMH9TIDIdk6 /9X3ni28Qx6xucTnBV6Tnss3+B5oeTeuvDjxLOEUMkfgdMHdF7qc9rZgLiOoWut/Gb/U OUmDjGPANQ9OXsMmZ7bB9X7RmWiGS28tZxMKmdYKjKGqDJPIJwXNRVUOocdpPASvmBYS 2phA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=Dr9pyVpWIz/Jd2ut7s7QHn+LJPfDxMdlERxwbqKyW28=; b=bGNI8ImiNQ2Ch81ZCEd7ztO/2l0H1VxlsGi8UYAUJfhjnNpo5XBiqF6oRkj3ASa11K gmlF48sN128TKipuEVA2xIgIEYyuLhUWHQR7PmSFjNTpb8vY98wW0D6/N35VE7K4AUIF 8vB+QpuArllS7DjKAndFk022vbUcr0XNZ7cuOvDj2LwxWs49PIIiA4wgcezwn5WQ5J4H Uo9ROdb8i9R7FlGNQTgGyI2Zpt1xRgC1y1t4uOM+gJyydN1P4lZe+bhy+0Adb3tYkOYL JWNGjxhwvYFM77firPplBHJ4D5ASR4jImPdvDo3JQiG7qTS1ve2wrzmmnBUJ+1VK0c76 PNUw== X-Gm-Message-State: AOAM531w+XzKBqt1UROvmL7jzgIlrDXdyWjomfpxjQRdahvL4pncF8Wi Z4uFBxTaCYoU64yuwC46FmJYUrMmZNc= X-Google-Smtp-Source: ABdhPJwWY4dsfYn5Y9uM/DDBjgVfvbGRvoJG8eLbbpoK4sO7t61glYPlNOPkGw3M8eQz4+mxYjqkJA== X-Received: by 2002:a1c:4302:: with SMTP id q2mr5655792wma.54.1591303394071; Thu, 04 Jun 2020 13:43:14 -0700 (PDT) Original-Received: from chametz ([185.220.101.33]) by smtp.gmail.com with ESMTPSA id p7sm9048530wro.26.2020.06.04.13.43.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jun 2020 13:43:13 -0700 (PDT) In-Reply-To: (Paul Eggert's message of "Thu, 4 Jun 2020 12:46:23 -0700") Received-SPF: pass client-ip=2a00:1450:4864:20::32c; envelope-from=pipcet@gmail.com; helo=mail-wm1-x32c.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:251863 Archived-At: Paul Eggert writes: > On 6/4/20 4:11 AM, Basil L. Contovounesios wrote: >> How would make-text-button detect whether its first argument is mutable? > > It could try to mutate the string, and catch the error that is thrown > when it's > not mutable. To be honest, I'd prefer a mutablep predicate, with a strong warning not to use it in the way that was suggested: (if (mutablep object) (do-something object) (do-something (copy object))) > No such error is thrown now and Emacs can crash or worse - but I > plan to arrange for one to be thrown. Have those plans been discussed anywhere? I get the impression it would help me to understand what you're planning to do. >> Would it not suffice to clarify in its documentation that it modifies >> its argument, in the same way that we warn about passing immutable lists >> to nconc? > > We could do that, yes. Some code passes string literals to make-text-butt= on, > though, and we'd need to change it. The first example I found was > ibuf-ext.el's > ibuffer-old-saved-filters-warning, which calls (make-text-button "here" .= ..). > Such code is already "broken" in some sense, so we'll need to fix it > anyway somehow. I fail to see how that code is broken: it uses an ephemeral string literal, just once, and gives it text properties. I don't think this is the best way of doing things, but it's a far cry from "Emacs can crash or worse". Am I missing something? > > On 6/4/20 12:26 AM, Pip Cet wrote: > >> I'm not sure the copy-sequence-unless-mutable semantics really >> make sense, though, as that might make bugs such as this one even harder >> to find. > > True. > >> I think we should add a new function with clean semantics, and throw an >> error in the old function if the string isn't "mutable", whatever that >> means in this context. > > Throwing an error matches Basil's suggestion. What sort of clean semantic= s did > you have in mind? Well, a documented return value would be a good start. The "BEG can be a string, in which case it's really the object, and we'll return it" thing is confusing, I think. I would suggest two functions, one which propertizes a string to be a button when inserted, and returns the propertized string; and one which adds text properties to make a range of an object (string or buffer) into a button, and doesn't return anything useful. >> (I guess I can't modify the string contents or >> add text properties, but can I modify existing properties? What about >> cons cells deep within the properties? If they're recursively immutable, >> what about markers and other objects that change state behind your >> back?) > > The test I was thinking of is pretty simple: you can't modify the > string object > itself, but you can modify the objects it points at. I think I can kind of decrypt that, but I'm not sure: keep in mind that currently, for example, (text-properties-at N STRING) returns the string's actual plist, so you can mutate it, which seems useless and potentially dangerous to me. (Please, let's change that?) Would you consider (text-properties-at N STRING) to be part of the string object itself, or an object it points at? > We could come up with > fancier tests later involving immutable property lists, but one thing > at a time > and maybe this one thing is good enough (at least it should avoid the > undefined > behavior). Which undefined behavior is that, precisely? It seems to me it would be pretty easy to define current behavior, though it wouldn't be very useful. >> I'm still surprised my patch fixed the problem here (for some buttons, >> at least, for others there are a few more places that do the same >> thing...) but not for Jo=C3=A3o. > > There are several instances of the same problem in SLY. I found the > ones in the > attached patch, and I expect there are others. So perhaps Jo=C3=A3o was > running into > one of the other problems. I think that was what was happening, yes.