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

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

> > consider quasi-quoted literals: would those be immutable?
> 
> A string literal should not be modified, regardless
> of whether it's quasiquoted.

You keep repeating the mantra that a string literal
should not be modified, with no good supporting
argument.

Elisp strings, and hence its string "literals" are
not your textbook strings and string literals.  The
latter are not mutable objects, with text properties.

Emacs strings are, in general.  And more of them
could be - they could even all be, I expect.

> "False sense" because programmers would start relying
> on Emacs to catch trivial mistakes involving modifying
> string literals? Horrors! (Programmers should let
> those mistakes persist into hard-to-debug complex
> programs, as this will give them much more of a challenge
> when debugging. :-)

With that logic, we should outlaw list modification.
Some users will make mistakes, or get confused, and
get into trouble.

Heck, why not take it even further: outlaw dynamic
state altogether - complex, difficult to reason about,
difficult to analyze and optimize by program, difficult
to optimize and parallelize.

Just a lot of trouble and headache, right?  All such
arguments are 100% valid.  And there are languages
based on them.  Lisp isn't one of them.  And by design
Emacs isn't based on one of them.

FWIW, I love purely declarative, applicative, logic and
functional languages.  Always have.  I love formal logic,
algebraic specification of ADTs, theorem proving, etc.

But I also appreciate the dynamic, side-effecting
"messiness" of dirty old bit-fiddling Lisp - and
_especially_ for a user-programmer editor/env such
as that dirty old man, Emacs.