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

[Paul Eggert <eggert@cs.ucla.edu>]

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). In my drafts so far
Emacs requires no more storage than it does now, and the CPU performance does
not change significantly, so overall this change should be a win in practical use.

It'd be a more-drastic change to add mutability/immutability as a more-general
concept to Emacs, to add new functions that freeze or check the mutability
status of arbitrary objects, etc., etc.. I'm not ready to propose that now and I
don't know if it'd be a good idea. My goal right now is to prevent Emacs crashes
and and general bugginess, not to add general mutability features.

> I think you've essentially documented the changes
> you're considering to propose as though they had already happened.

No, I first discussed and wrote those changes in response to a bug report, and
only later looked into conservative ways of fixing some of the real problems
uncovered by that documentation effort.

> 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'm limiting myself
just to strings for now, as they're the most salient part of the problem (core
dumps and all). It should be OK to do that, and put off the more-general issues
until later (if we ever do that at all).

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).