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: master f51f963: Fix some side-effecting uses of make-text-button Date: Sun, 07 Jun 2020 09:21:17 +0000 Message-ID: <87d06bxmcy.fsf@gmail.com> 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> <87lfl0x9qi.fsf@gmail.com> <785d730e-23b2-dcad-105c-80ac5074b5dc@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="40792"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: "Basil L. Contovounesios" , Stefan Monnier , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 07 11:22:08 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 1jhrVH-000AUl-Uq for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Jun 2020 11:22:07 +0200 Original-Received: from localhost ([::1]:55544 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhrVH-000502-1j for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Jun 2020 05:22:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36892) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhrUh-0004Xa-LX for emacs-devel@gnu.org; Sun, 07 Jun 2020 05:21:31 -0400 Original-Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:41612) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jhrUg-0003n4-Oh for emacs-devel@gnu.org; Sun, 07 Jun 2020 05:21:31 -0400 Original-Received: by mail-wr1-x42f.google.com with SMTP id j10so14197968wrw.8 for ; Sun, 07 Jun 2020 02:21:30 -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; bh=t412kdtkcRAqY5pLLg1VsMdAWUFRCHCD6azOwp0AIpA=; b=gG0FOB1apZcklmYaCtmaVqdi5jvjF/yKuAORY2LxJpU+ncLaJe+ynw50BLQ5Wx7YBR OIvGaM5Dp9xcOkSA5gxhnyprOp17Vj08+IoVro1DF9tkUCPBx+saaDYevedmR/ySoyNW KD3e+Ciw36mREqyTzyvRLhA9kyfaomR+SjGSC5O+JA88TO6VdDm5Lyb6ya+BKY5KHMwR IES2boqLFJUSRHlqEwjcfmRwXGhOvoEW3sI53izh5okrdOko3vTEe3rd51POpzqGN+VV iaQxEn2Bg3o7yiIOJkMPbXeM/eYwi7AAlI0jHeNFaetLKZTRYeKaqXmHIAZ9UzOEtJXl DUlA== 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; bh=t412kdtkcRAqY5pLLg1VsMdAWUFRCHCD6azOwp0AIpA=; b=ld48qkrrsWGXrlfWKAxwevZXM95w0bdKriIBzNLETxQ0DxSIVpi40mE56bLBLoRYfn nc5oeWnMysgwZ9d6m+FnVvFrkOR5Bu3knszXMz1KbXv6253sA7THZqgeghtWhxJe1ZAK u41VSmsimvqeX9V3146jp7m5NegHFS55mlQtfi61iso1YfeLpzS/k4MTDdhVvxdn/LcL MHYKnI+X9337D96y33lE6yP2zLxB1/NlEyF6ypceTmNT+FnxKQ1nymmcz56QvRhsendw ur9/rMHx1G/AxWB38RxloBHoIjLoQHEuMyQZswv1DCvwder7rAK35zR+z/j24g/glSGG /0uw== X-Gm-Message-State: AOAM533o6XEiau5e6YQt/utzMM3KUmXoMKqXItb0duPRiywEw4QQcV3r kGfB+j/M2ffz8UB4WW4Kwht7Q/bCl5k= X-Google-Smtp-Source: ABdhPJzDLcASaspvqabnKTxBg7l8E0iigj/D1VEhGOcu4+3I96lDw+JzLQ3fdPCi1gseaaxb8B7r2w== X-Received: by 2002:a5d:4490:: with SMTP id j16mr19582115wrq.276.1591521688918; Sun, 07 Jun 2020 02:21:28 -0700 (PDT) Original-Received: from chametz ([51.158.111.157]) by smtp.gmail.com with ESMTPSA id l17sm19549853wrq.17.2020.06.07.02.21.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jun 2020 02:21:28 -0700 (PDT) In-Reply-To: <785d730e-23b2-dcad-105c-80ac5074b5dc@cs.ucla.edu> (Paul Eggert's message of "Sat, 6 Jun 2020 13:15:35 -0700") Received-SPF: pass client-ip=2a00:1450:4864:20::42f; envelope-from=pipcet@gmail.com; helo=mail-wr1-x42f.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:251997 Archived-At: Paul Eggert writes: > On 6/6/20 12:41 PM, Pip Cet wrote: > >> What I'm fighting against is a certain model of >> immutability being installed into the Emacs source tree and effectively >> preventing better ones from ever having a chance, as well as turning out >> to be, as the vast majority of such models have, a problem rather than a >> useful feature. > > I'm quite conscious of those dangers. What I had in mind was something > far more > limited: just supporting runtime checking of attempts to modify strings that > either have undefined behavior if you mutate them now, or are close enough to > that category so that nobody will care about the difference (except to > be happy > when Emacs catches unlikely glitches in their programs). Okay, I'm looking forward to that proposal, and sorry for criticizing it before I'd understood it clearly. >> if we want that C API to be flexible enough to allow unusual >> applications (and isn't that what Emacs is all about?), it needs >> something more than just the obvious CHECK_MUTABLE (obj) macro. > > It sounds like you're thinking ahead to the non-string case. I am. > I'm > limiting myself > just to strings for now, as they're the most salient part of the problem (core > dumps and all). The core dumps definitely need to be fixed. I still don't understand precisely how far you're planning to go in protecting an immutable string's text properties, but you've convinced me that it's a win in practice even if we just protect the characters. > It should be OK to do that, and put off the > more-general issues > until later (if we ever do that at all). So this would be only strings, not cons cells? That makes sense to me. > The obvious check_string_mutable function doesn't need to be used very often: > only in the places where CHECK_IMPURE is used on strings now. The only other > primitive I've found the need for at the C level is freeze_string (to mark an > already-constructed string as being a constant). Just to be clear: there's no way to unfreeze a string, right? Because that would add considerable complexity and not be worth it, IMHO.