Re: invisible text and point

[Luc Teirlinck]

I posted a follow-up to my original message from yesterday evening
this morning.  I no longer propose "reverting" to the emacs-21.3
behavior (actually, I only did this because I misinterpreted it
yesterday, as I noticed this morning), but "mimicking it better", by
making sure that (point) returns the position of a visible character.

Since my conjecture that the infinite loops were also related to the
problem was apparently a premature conclusion based on the fact that
the bugs did not occur in 21.3 and happened at similar places as the
other bug, we are left with the m and RETURN bugs in info.  Just
fixing those individual bugs would not really seem to really address
the problem, which is more general.  Namely a huge fraction of Emacs
commands act based on the return value of (point).  Since point is not
where the user believes it is, this is bound to confuse the user.  I
do not know whether it would be feasible to make all interactive
commands act based on the "user-visible" displayed position of point
instead.  That would really eliminate the need for any change.

Stefan Monnier wrote:

   Point is not put inside the invisible text.  It's put at one of the
   two ends.  In this case it happens to be "just before" rather than
   "just after" because the stickiness is the default one so that inserting
   a char at the end would lead to a hidden char whereas inserting a char
   at the beginning would lead to a visible char: the choice is to prefer
   putting point at a position such that inserted text is visible.

   I believe that the `intangible' change mentioned underneath in the NEWS
   file did the same for intangible&invisible text.

Yes, but semantics aside, if (point) returns the position of an
invisible character, we have the kind of problems of which the m and
RETURN behaviors in info are symptomatic.

   Or rather make it "front-sticky" rather than "rear-sticky", such
   that when the user sees point in front of letter "a", `char-after'
   will indeed show letter ?a.  Right now, it's the opposite: if point
   is right after letter "a" `char-before' will indeed return ?a.

That would work for those buffers.  I would guess that there probably
are good reasons to keep invisible rear-sticky in general.  In that
case, we would be left with the problem of making sure that the user
would understand in which buffers invisibility is front-sticky and in
which it is rear-sticky.

Sincerely,

Luc.