Re: Cursor positioning with `after-string' overlays

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Thu, 01 Apr 2010 18:06:26 -0400
> Cc: address@hidden
> 
> > 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.

Sorry, I don't understand the specific situation.  In my example, when
the cursor is on `b', insertion happens between `-' and `b', which is
visually correct.  Can you modify my example to create the situation
you are describing?  Then I could try to reason about it and perhaps
modify the code if necessary.

In any case, do you really think that being unable to put the cursor
on `b' (with the old code) is correct behavior?  The `after-string'
does not replace `b' on the screen and doesn't cover its position, so
this behavior looks like a subtle bug, since `b' comes from the
buffer.

> 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).

What do you mean by ``the insertion-type of the marker''?  I've seen
your comments in minibuffer.el about something similar, so perhaps now
is the time to add whatever features you thought were absent.

> 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).

This may make sense when the string is displayed _instead_ of some
portion of the buffer, or perhaps when we have a single buffer
position that uses up several columns on display, like in Kim's
example with a TAB in Cua Mode.

But if you type C-f, which moves point to the next buffer position,
and the glyph produced from that buffer position is displayed on the
screen, how can it be TRT not to place the cursor on that glyph?

> 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).

I think this kind of problems should be fixed, not worked around with
the `cursor' property.  The cursor-positioning code does not work only
on glyphs, it does search the buffer for `display' properties and
overlays, so whatever information is available in the buffer, the
cursor-positioning code can get at it.