Re: Cursor positioning with `after-string' overlays

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

>> > 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.
> Then you need to use the "integer as `cursor' property value"
> feature.  I.e., don't just set the property's value non-nil, set it to
> the integer number that specifies how many buffer positions are
> ``covered'' by that cursor positions.  That's what CUA Mode does in
> cua-rect.el.  Integer property values do override the "exact match for
> point always wins" strategy.

Yes, that sounds OK.  But note that (except for when the after-string is
at EOB) there's basically always a "exact match for point", so that
basically means that the use of a value t for the `cursor' property will
simply not work any more and might just be dropped.

>> 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.
> Right, but we have the string, so we could look for the overlay that
> specifies the same string.

Yes, we could, tho of course the same string might be placed on several
overlays at the same buffer position, and we have to check whether it's
on a before-string or an after-string or ...
I.e. it's workable but it'd probably be ugly.

>> 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.
> I'd need to see the requirements first.

Just that it places the cursor on the "before" or "after" position of
(after|before|display)-strings depending on the
stickiness/insertion-type of the corresponding overlay/text-property.


        Stefan