Re: Should invisible imply intangible?

[David Kastrup]

Richard Stallman <address@hidden> writes:

>       In particular, how would your model treat an overlay
>     having a display property with an image in it, when the text up to and
>     including character 10 of the buffer was invisible (due to a text
>     property, for example), and both overlay-start and overlay-end are 11.
> 
> Your previous statements did not say that you meant empty overlays
> only.

Nor did this statement.  The point I wanted to make but apparently
failed to get across is that any behavior for treating the
invisibility property should work consistently with the special case
of empty overlays.

> I was thinking of nonempty overlays.  For empty overlays, the
> treatment you proposed might be right.  At least it seems plausible
> to try.
> 
> It would be useful to have functions to get the text properties (or
> just one of them) that would be inherited by an insertion at a given
> buffer position.  It looks like that would be useful as a subroutine
> for many purposes.

Now this failure to get my meaning across certainly is my fault for
using the wrong words.  What I wanted to make the behavior depend on
was not the stickiness of properties, but actually the marker
insertion type of the overlay boundaries.  I apologize for the
confusion.  Probably with text properties indeed the stickiness might
be interesting, but here I am currently concerned with overlays.

Let's try to come up with the most consistent behavior for cursor
display and invisibility display.

As Stefan (or was it Miles?) has already remarked, the default
display of cursors should preferably be such that an insertion of new
characters will occur at the location where the cursor is visible.
Let's first talk this through without the further complication of
invisibility.

If point is on the first character of a text-range with a
before-string property (this property only works with overlays), this
means that the cursor should display on the first character of the
range if the insertion type of the overlays begin marker is
don't-move-on-insertion, but it should display on the before-string
itself if the insertion type is move-on-insertion.  Similar behavior
would apply if point is on the first character following an overlay.

Ok, now we have the case that the cursor is usually moved out of
invisible areas (point adjustment) and currently cannot be positioned
immediately behind an invisible area so that cursor movement does not
appear to hesitate.  If the cursor is kept out of invisible areas, it
makes sense to try to define the insertion such that wherever a legal
cursor position is, insertion characters will not insert into the
invisible area.

This cannot always be achieved: when the overlay-beginning marker is
of the stay-before-insertion variety, and the overlay-end marker is
of the move-after-insertion variety, there will be no cursor position
between the preceding visible and the following visible character
where inserted characters would not become invisible.

The other cases can be dealt with consistently: if both markers are
of the moving variety, we want to have the cursor position before
the overlay legal.  If both are of the staying variety, we want to
have the cursor position behind the overlay legal.  If the front
marker is of the moving and the end marker of the staying variety, I
would tend to make the position behind the invisible overlay legal (so
that the overlay does not move), and the pathological case where
inserted characters disappear should be treated the same so that
successively entered invisible characters will appear (after point
adjustment) in the right order at the end of the invisible area.  If
the position before the invisible area would be the legal one, then
one character would get inserted invisibly, but then the cursor would
move to after the character following the overlay -- unpretty.

Now to the visibility of before-string and after-string: as pointed
out already, it is a common idiom to set some text (often just an "x")
to invisible and place a before-string or after-string for an image
instead, so we would not want to have those disappear in the common
case.

Afraid I am too tired currently to work out this in detail, too.  If
anybody cares about these sort of ramblings, I can try to think about
it later.

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