Re: invisible text and point

[Luc Teirlinck <teirllm@dms.auburn.edu>]

Stefan Monnier wrote:

   Yes, we need to address those.  Making invisible front-sticky and
   not rear-sticky (in the info buffer) is easy enough.

Yes although, as you pointed out, that might in certain situations
produce non-intuitive results for commands that check char-before (or
both char-before and char-after) for what to do.  Seems that we can
not win either way.  The change would automatically fix the bugs with
m and RETURN in info, although it would, of course, also be possible
to fix these without any change in the treatment of invisible text.

To make things worse, the invisibility property is not the only text
property that appears to give problems of the "things are not always
what they really seem" type.  The display property can be just as bad.

Indeed, do C-h i again and put point near "* echo".  Suppose that for
some reason we might want to take a look at the man page for echo,
maybe to see how it differs from the info we just come to read (or
whatever).

M-x man RETURN.

Result:

Manual entry (default echo                     ):

Lots of useless whitespace at the end, but that is perfectly OK, one
can do M-x man echo and add tons of trailing whitespace, it gets
disregarded anyway.  So: RETURN.

Result:

error in process sentinel: Can't find the echo: manpage

In other words, in spite of not only what seemed to be in the buffer,
but even in spite of what the prompt seemed to say, the default was
not really "echo" but "echo:".  Who would have guessed?

Actually, the text on the line is:

echo: (sh-utils)echo invocation.              Print a line of text.

The user does not see the:

: (sh-utils)echo invocation.

But to play semantic games (that have some relevance), that text is
completely "visible" (line-move-invisible returns nil for all involved
positions and there are no invisibility properties around). It just
has the display property.

All of this would seem to be very confusing to the user.

Sincerely,

Luc.