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

[Drew Adams]

> > 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.
> 
> I think there needs to be a clarification here: the issue is about
> modifying data (here specifically strings, but the issue applies to all
> other such data) that appears as literal in the code.

Yes, I know.

> This issue is not one of optimization (preventing those modifications
> would likely impose a slowdown, if anything) but one of detecting usage
> that is usually a bug (one that leads to people being utterly
> confused by the resulting behavior).

The resulting behavior now is undefined/unpredictable
in the problematic cases.  That's the problem.

List-structure modification too can result in
application bugs and confusion.  That's not a
reason, in Lisp, to prevent such modification.
Lisp, including Elisp, gives you lots of rope
to hang yourself with.

A "literal" string occurrence in code is what
the implementation of Emacs defines it to be.

Strings can have text properties.  Those are not
visible as program text (code, viewed lexically).
Maybe no strings in Elisp should really be
considered "literal" in the usual sense.

Unless some sophisticated analysis takes place,
to determine that no modification of a given
string's properties will/can/might take place,
there are two "extreme" positions possible:

1. Disallow modification of a string's text props.
2. Allow modification of a string's text props.

Something in between is also possible.  We have
something in between now, but it's unclear or
undefined or accidental.

As I understand it, Paul proposes extreme #1.
I'm closer to extreme #2.

But I say that any backtracking from #2, and
especially any backtracking from what Emacs has
had so far (ad hoc, accidental, partial, or what
have you) - any considering a string ("literal"
or not) as needing an error to be raised if an
attempt is made to change its text properties
(including adding some when there are none) is
a loss.

And any such loss needs to have a good supporting
argument - as strong an argument as for raising
an error for list-structure modification where
today there's no such error-raising.

Elisp programmers need to be able to do both:
(1) program without structure modification (list,
string, whatever), and (2) program using such
modification.

And the "literal" case really shouldn't, I think,
be a special one.  I think that now, even for a
quoted list, but I won't argue that case.  (A
quoted list is clear just from the program text.
A propertized string is not clear textually, in
the general case.)

I don't expect others to hold the same "extreme"
position.  But that's the direction I'm thinking
in now, FWIW.  And so far I haven't seen any good
arguments in the other direction.

We heard arguments about important "optimization".
You've tossed that aside now, at least for literal
strings, saying there's no such optimization and
in fact there may be a performance cost.

Your argument is instead the value in "detecting
usage that is usually a bug (one that leads to
people being utterly confused by the resulting
behavior)".

That needs to be shown.  And not just by pointing
to the current all-bets-are-off situation in terms
of understanding.  Please make the argument in terms
of a situation where every string is considered to
have modifiable text properties (extreme #2).

When I see a good argument against #2, maybe I'll
pull back from it a bit. ;-)

Certainly, the general argument against this kind
of thing _is_ in terms of (1) simplicity of program
analysis and (2) performance.  It's the argument of
compilation vs interpretation, more or less.

I'd argue that Emacs Lisp is, among all the Lisps,
the one where use by end users of the result is the
most important, and interpretation (vs compilation)
is relatively more important than for other Lisps,
and performance and static (lexical) analysis is
relatively less important.

(And that's from someone who wishes that Elisp would
take more from Common Lisp, which is far from #2.)