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

[Drew Adams <drew.adams@oracle.com>]

> It might be worth making such a significant change if
> modifiable string literals were an important feature

They are, IMHO.  A wonderful feature.  Other Lisps
should be so lucky.

> that Elisp programmers urgently needed.

Urgently?  As in an emergency?  No.  That's a pretty
high bar.  Do your proposed wholesale changes in the
other direction handle an emergency?  Urgent?

> But they're not: they're rarely used,

Evidence?  But let's assume your guess is right.
Is frequency of use really an important criterion
here?

List modification in Lisp is infrequent, but it's
very important to Lisp - always has been, outside
the use of "pure Lisp" for some research purposes.

> partly because when they have been used their use
> often caused subtle bugs (as we've seen with
> make-text-button).

That's because there are bugs in the implementation.
And because there's not corresponding doc everywhere.

The same thing is true of list-structure modification.
(I hope your next crusade won't be to prevent that!)

> They're not a feature worth fighting for,

Your opposite "feature" isn't, IMO.

> any more than mutable numbers would be.

Wrong.  An Elisp string is an object, with properties.
When Elisp numbers get text properties your comparison
might make some sense.

> >> This will hurt performance a bit since it will
> >> disable some optimizations.
> >
> > Which ones?
> 
> The ones Emacs is currently using, such as some strings are in read-only
> shared memory, and some are coalesced. It would be unreasonable to coalesce strings
> if they were mutable, since that would mean changing one would change the other.

What's the cost in lost optimization?  Any plan to
fiddle with optimization should weigh the gain and
loss.

To you, there's apparently no loss, because you see
no value in modifying string properties (or at least
that's not important enough to keep - to "fight for").

> What I'm thinking of proposing ... is that Emacs signal
> an error if a program attempts to change a string constant's
> characters or text properties.

Very not-good.  What's next, impossibility to
modify list structure?

> That's a simple notion,

It sure is.  Too simple.  And unlispy.

> and it's something that Emacs long did for preloaded
> strings so it's not like this would be a giant revolution.

That some instances of a class of objects can be
immutable is very different from denying all such
objects the ability to change.  Yes, that's a
giant, and ill-conceived, revolution.

> To my mind it's a considerably more-conservative
> change than the one you're suggesting.

"Conservative" or ultraconservative?  It goes
backward IMO, tossing out an important feature of
Emacs Lisp.