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

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

On 6/5/20 5:46 AM, Pip Cet wrote:
> I get the impression we
> shouldn't discount the possibility that the current way of doing things
> (after pure space) isn't so bad at all: all strings, vectors, and cons
> cells are mutable to the same extent.

That's not the current way of doing things, and although the area is murky there
have always been Emacs Lisp objects that are not mutable. For example:

(aset (symbol-name 'cons) 0 ?d)

This signals "Attempt to modify read-only object" error in Emacs 25, and makes
Emacs dump core in Emacs 27. And there are other cases like that.

Obviously we need to do better in the dumping-core area. When we do that, we
have an opportunity to simplify and/or document behavior in this area.

If we decide to simplify/document by saying "all strings are modifiable" then
we'll need significant work at both the C and Lisp level to do that. This will
hurt performance a bit since it will disable some optimizations.

If we decide to simplify/document by saying "an error is thrown if you try to
modify a string literal" then we'll need to add some code to do that. I have a
draft of something along those lines. It doesn't hurt performance significantly
in my standard benchmark of 'make compile-always'. Although it invalidates some
existing code, such code is quite rare and is already relying on undefined behavior.

If we decide to leave things alone, they will remain complicated and murky.