Re: Cursor positioning with `after-string' overlays

[Stefan Monnier]

>> See my sample code above again or think of the minibuffer messages
>> during completion: depending on the particular case, the intention of
>> the text inserted via an after-string may be to appear "before" or
>> "after" the cursor.

> The minibuffer completion use-case is different: there, we have no
> text that comes from a buffer beyond the place where the cursor is
> displayed.  IOW, there're no glyphs to the right of the cursor that
> came from the minibuffer.  So there are no buffer positions that
> "compete" for the cursor position, only the overlay with the
> completion message.

I can imagine using the same kind of message for in-buffer completion.
So in my view the fact that there's no buffer text after the overlay in
the minibuffer completion case is just a lucky accident.

>> I seem to remember that one of the problem is that at the
>> moment we handle the cursor position all we know is "we're displaying
>> string S", so we know the text displayed comes from a string rather than
>> from a buffer, but we don't know where that string comes from: we've
>> forgotten all about whether it's from a display property, or an overlay,
>> so we can't check the corresponding stickiness/insertion-type.
> There's no "memory" in the glyphs of where the string came from,
> that's true.  But that doesn't mean we cannot resurrect that
> knowledge.  We already do something like that, see the call to the
> function string_buffer_position_lim inside set_cursor_from_row.  If
> required, we could extend that function, or call it for other similar
> jobs when we position the cursor.  Or we could record the buffer
> position where we found the string, and remove the need to look it up
> again during cursor positioning.

The position is not enough because we need to find the actual overlay
where it came from and there can be several overlays at that buffer
position.

But I do not object at all to your general argument "I think this kind
of problems should be fixed, not worked around with the `cursor'
property".  I seem to remember making the same observation, then jumping
to the C code, and finally deciding "too hard for me, I'll live with the
workaround for now".  So if you can fix it, that would be great.


        Stefan