Re: invisible text and point

[David.Kastrup@t-online.de (David Kastrup)]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> 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.

Of course.  The purpose of the invisible property is to actually have
the characters in question appear in the buffer.  If you wanted to
attach some information to text that would _not_ influence editing,
you would put it into text properties, for example.

> 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.

Again, the purpose of this property is to make things different from
what they really seem, so it is hardly surprising that it succeeds.

> 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.

Which is the reason one would have to fix this right there in the code
at the place of usage.  One can't cook up semantics for invisible and
display that will be perfect in all situations, so one has to cater
for those situations explicitly where it turns out the chosen
alternative does not fit.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum