[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cursor positioning with `after-string' overlays

From: Eli Zaretskii
Subject: Re: Cursor positioning with `after-string' overlays
Date: Sat, 03 Apr 2010 00:16:52 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Fri, 02 Apr 2010 16:35:50 -0400
> > 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.

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

Right, but we have the string, so we could look for the overlay that
specifies the same string.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]