Re: master f51f963: Fix some side-effecting uses of make-text-button

[Pip Cet <pipcet@gmail.com>]

Paul Eggert <eggert@cs.ucla.edu> 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.