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

[Drew Adams]

> >> It might be worth making such a significant change if
> >> modifiable string literals were an important feature
> > They are, IMHO.  A wonderful feature.
> 
> I find it very hard to believe.

Me too.  But that's my current vision, and I'm
stickin to it, until I see some good arguments
to the contrary.

Show me why we need (ever) to treat Elisp strings
as immutable, at least wrt their text properties.

> Either you're misunderstanding what we're talking about, or you do have
> some really off programming habits.
> 
> Could you show some examples of code that rely of that "wonderful
> feature"?  Extra points if such code is available in an existing
> Elisp package.

I don't have an example.  I don't have any such
habit.  And we don't yet have consistently, clean
mutable literal strings.  Show me that we couldn't.

Elisp strings can have properties.  You don't see
the properties when looking at code.  Neither does
the Lisp reader etc.

I don't see why we would think of strings appearing
in Elisp code, i.e., literals, the way we think of
them in C, as fixed things, constant.  It's natural
that a programmer might think that way.  But I don't
see why it's important to the Elisp language that we
treat them that way.  Please explain why it is.

What's lost by treating them the same way we treat
a value returned by `make-string' or `copy-sequence'?

The `make-text-button' example is maybe a good example
of why we shouldn't need to bother to constantize them.
Dunno; I didn't really follow that discussion.

TBH, I haven't thought about this before this discussion.
But I'm wondering now why we ever try to treat Elisp
strings as constants - wrt their properties, at least -
rather than as mutable objects.

Sure, it's unusual to think this way.  But it's pretty
unusual for a language to have propertized strings in
the first place.

The case of strings is different from both conses and
symbols (with their properties), admittedly.  And?