[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.
- Cursor positioning with `after-string' overlays, Eli Zaretskii, 2010/04/01
- Re: Cursor positioning with `after-string' overlays, Stefan Monnier, 2010/04/01
- Re: Cursor positioning with `after-string' overlays, Eli Zaretskii, 2010/04/02
- Re: Cursor positioning with `after-string' overlays, Stefan Monnier, 2010/04/02
- Re: Cursor positioning with `after-string' overlays, Eli Zaretskii, 2010/04/02
- Re: Cursor positioning with `after-string' overlays, Stefan Monnier, 2010/04/02
- Re: Cursor positioning with `after-string' overlays,
Eli Zaretskii <=
- Re: Cursor positioning with `after-string' overlays, Stefan Monnier, 2010/04/02
- Re: Cursor positioning with `after-string' overlays, Eli Zaretskii, 2010/04/03
- Re: redisplay code is ugly (was: Cursor positioning with `after-string' overlays), Eli Zaretskii, 2010/04/03
- Re: Cursor positioning with `after-string' overlays, Eli Zaretskii, 2010/04/03
- Re: Cursor positioning with `after-string' overlays, Eli Zaretskii, 2010/04/03