Re: Cursor positioning with `after-string' overlays

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Fri, 02 Apr 2010 14:17:31 -0400
> 
> > 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.
> 
> Try:
> 
>     (let ((pos (goto-char (point-max))))
>       (insert "foobar")
>       (overlay-put
> 	(make-overlay (+ pos 2) (+ pos 3) nil nil t)
> 	'after-string (propertize "-" 'cursor t)))
> 
> (i.e. I added "nil nil t" to the call to make-overlay).

Thanks, I will study this.

> >> 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.
> 
> Exactly, yes.

Okay, this kind of use-cases already works with the new code as it
did with the old (as far as my testing goes).

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