Re: Should invisible imply intangible?

[David Kastrup]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

> >     isearch-open-invisible will call a user-supplied hook in order to make
> >     invisible texts appear when searching.  Those images I use in my
> >     buffer effectively make the original text invisible (for example, I
> >     replace $\frac{\pi}{3}$ by an image for the formula), so I want
> >     isearch to "open" them while going through the buffer.  isearch will,
> >     however, only call isearch-open-invisible if the text/overlay is
> >     marked as invisible, so that is what I do.
> > 
> > It would make more sense to modify isearch-open-invisible so it can
> > deal with these images in another way.  The invisible property should
> > override the display property and make the text it covers not appear,
> > not as itself, not modified by a display property.
> 
> I'm not completely sure about that.  After all, why would someone
> put a `display' property on an `invisible' overlay if the `invisible'
> property means that the `display' property will be ignored anyway ?
> 
> In the case of `display' properties, I agree that your point of view
> might be acceptable, but in the case of `before-string' and
> `after-string' it is clearly not so, because it is very common to
> use an overlay with both the `before-string' and the `invisible'
> property in order to replace a piece of text with another.

Ok, I'll try now to be as pedantic as possible with regard to this.
If we make a large text area invisible, and there are some images
contained entirely within it, we would usually want to have them
disappear together with the hidden text.  Now in the case of overlays,
those are not connected with single characters, but with buffer
positions.  What to do in case an overlay ends exactly on a boundary
between visible and invisible text?  If we are at a boundary where
invisibility starts, the before-string is to be displayed before the
overlay, before invisibility starts.  If we are at a boundary where
invisibility ends, the after-string is to be displayed after the
overlay, after invisibility ends.  Since the invisibility property of
the overlay is proposed by Richard to be equivalent to the covered
text bearing an invisibility property, it would be entirely
consistent to let the before-string and after-string show in the case
that invisibility starts at the start of the overlay, or ends at the
end, respectively.  If you want to have the invisibility extend to
the before-string and after-string also in case where they sit on a
border of invisibility, add the appropriate text properties to the
strings themselves.

Now the question remains what to do with the display property itself.
In case the overlay lies completely contained within an invisible area
(as determined by text properties or another overlay with invisible
property), it should not display.  That much is obvious.  But if start
and/or end lie on the edge, what should we do?  If we really are
pedantic, the behavior will depend on the stickiness of the
invisibility borders.  If a character inserted at the front of the
overlay will be visible (namely the overlay-start marker is of the
moving type and the text invisibility comes from the overlay), the
overlay can be visible.  If a character inserted at the end of the
overlay will be visible (the overlay-marker of the non-moving kind),
the overlay can be visible, too.  If one would want finer control,
one would put a string into the display property.  Unfortunately, a
display property on characters of this string gets ignored, so there
is no way to show an image via that path.  I would prefer it if
recursive display properties would be heeded (perhaps with a hard
limit on the recursiveness, but exceeding the single level allowed
currently).  The most desirable semantics are less than clear here.


> In such a case we again end up with `invisible' text which does have
> a screen representation so that having point before or after the
> invisible text is user-visible (just as is the case with ellipsis),
> which implies that we again shouldn't prevent the user from placing
> point immediately after the invisible text.

Actually, there is a fine distinction here.  The cursor can never be
immediately before a before-string.  It is either strictly before the
start of the overlay, in which case it is one character away from the
before-string, or it is on the first character of the overlay, in
which case it is _after_ the before-string.  It would make no sense
to let it jump before the before-string once the text gets made
invisible, so the cursor as an indication of point will never appear
immediately before a before-string image.  In a similar vein, it can
never appear to be on an after-string image, but either on a
character before it, or on one after it.  The cursor *can*, however
appear on an image displayed with the display property.

> I hope you're beginning to see what I meant when I said that it's
> not easy to determine when a piece of `invisible' text really has no
> effect on screen.  Checking the invisibility-spec is not enough: you
> also have to check the presence of a `before-string' or an
> `after-string' or a `display' (although this last one might
> disappear if you decide that its behavior should be changed) and
> maybe there are other cases.

'display can carry various items.  Some *modify* the text under
consideration (different faces, for example).  The modifications
should certainly be made invisible together with the text affected by
invisibility spec of the overlay itself.  But those display properties
that *replace* the text altogether, well... see the above.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: address@hidden