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

[Drew Adams]

> >> 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.
> 
> Lately, only pure ones, as far as I can tell?
> 
> > 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.
> 
> Well, dumping core is bad. The problem here is how pdumper "changed"
> pure space (actually, we're putting several megabytes of zeroes into
> every Emacs binary as a result) and how make_pure_c_string tries so very
> hard to save a few kilobytes of memory. Both problems, as I said, that
> wouldn't exist if we simply removed pure space.
> 
> > 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.
> 
> Indeed. Simplify: remove pure space. Document: all strings, vectors, and
> cons cells are mutable to the same extent.
> 
> > 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.
> 
> I don't see why. All strings are modifiable, but the byte compiler will
> identify strings under certain circumstances. That doesn't violate the
> simple rule that as far as the Emacs core is concerned, all strings are
> equal.
> 
> > This will hurt performance a bit since it will disable some optimizations.
> 
> Which ones?
> 
> > 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
> 
> So far, what you have proposed is "an error is thrown if you try to
> modify the characters of a string literal, or if you add text
> properties unless it already has some, or if you remove the last text
> property".
> 
> > draft of something along those lines. It doesn't hurt performance
> > significantly in my standard benchmark of 'make compile-always'.
> 
> (In general, I think that's probably not a good benchmark to optimize
> Emacs for).
> 
> > Although it invalidates some existing code, such code is quite
> > rare and is already relying on undefined behavior.
> 
> I'm not sure "undefined behavior" is a useful term when speaking about
> Emacs Lisp, except for behavior which is explicitly documented to be
> unreliable. There's a single implementation, and a lot of code is
> written to conform not to what's documented but to what happens to
> work.
> 
> > If we decide to leave things alone, they will remain complicated and murky.
> 
> But I'd call the behavior you suggest even more complicated.

Amen.

> I still think there's a significant risk that there will be ad-hoc
> changes that essentially commit us to a simplistic model of
> mutability. I don't think they're necessary or urgent, except for the
> make_pure_c_string bug you describe.
> 
> For example, I think it might be very useful to have an immutable "view"
> of a mutable object (as in C, where I can pass a char * to a function
> expecting a const char *); that would mean storing the mutability flag
> in the Lisp_Object, not in the struct Lisp_String.

+1.  All that Pip says here makes sense to me,
as far as I understand it.  (I can't speak to the
implementation matters, e.g. use of pure space.)

If someone has the cycles and will to improve
things by making the modification of strings,
including what look like literal strings in
code, easier and more flexible - in particular
text properties, great.

But going backwards, toward some perhaps unneeded
optimization, in the direction of systematically
raising an error when trying to modify text
properties of a string, is not a good idea, IMO.

Before even considering optimization there should
be some analysis of what would be gained and what
would be lost.

Yes, currently there is some mess and uncertainty.
But there are good and bad cures to mess and
uncertainty - different kinds of "cleanup".