Re: Cursor positioning with `after-string' overlays

[Stefan Monnier <monnier@iro.umontreal.ca>]

> found.  IOW, exact match wins over all other considerations.  Since
> C-f from the second `o' moves point to buffer position to which `b'
> corresponds exactly, that is where the trunk version puts the cursor.

But depending on the insertion-type of the end marker of your overlay,
text inserted "at point" will be inserted (visually) between the o and
the - rather than between the - and the b, so while this choice would
sometimes be correct, it's sometimes incorrect.  That's why we have the
`cursor' property (although admittedly, for this particular use, the
insertion-type of the marker should already provide the needed info).

> More generally, what are the use-cases for putting the `cursor'
> property on a `before-string' or `after-string' overlay, and what is
> expected from cursor positioning in those use-cases?

AFAIK, there are a few different use cases for the `cursor' property.

One use case is when you simply want to control where the cursor is
displayed on a piece of text that's not in the buffer (typically an
after-string).  In such a case, without any extra information, it would
not be incorrect to place the cursor before the after-string, or after
the after-string or anywhere in between.  So the `cursor' property
allows to specify the intended behavior (e.g. the after-string has the
form "()" and you want the cursor to appear in between the two parens).

The other use case is when the cursor positioning code gets it wrong
because it works at too low a level (typically the after-string or
similar thingy is on an overlay with carefully chosen stickiness which
should make it clear whether the cursor should come before or after the
string, but the cursor positioning code only gets to see a "flattened"
representation of the text, so it can't know the stickiness property).


        Stefan