Re: Moving point around empty overlays with 'after-text

[Platon Pronko <platon7pronko@gmail.com>]

On 2023-04-10 16:03, Eli Zaretskii wrote:
>> front-advance and rear-advance control if the typed text should be included in overlay. In case of inline type hints, typed text never needs to be included.
> 
> Is that the only effect of front-advance and rear-advance in this
> case?

I get your point, you are talking about moving the overlay forward if characters are typed before the overlay :)
But for zero-width overlays it never moves the overlay - I tested different variations, and right now no combination of these properties allows one to insert characters before the inlay:

nil nil => characters are inserted after the overlay
nil t => characters are not visible (because they are inside overlay)
t nil => characters are inserted after the overlay
t t => characters are inserted after the overlay

>> I did. All these examples are about consitently positioning cursor before or after overlay at all times, and they of course work. But none of them allow cursor position to move from beginning to the end of overlay without nasty hacks with detecting cursor position and manually changing overlay properties.
> 
> I'm not sure which part(s) are considered "nasty hacks" in your eyes,
> given that you are already okay with using "empty" overlays for
> displaying the hints.

I'm definitely not okay with using empty overlays. My whole point is that it would be nice to have some alternative well-defined way to have inline text, and not resort to trying to force overlays into doing what they are not supposed to. Currently lsp-mode, eglot, company-mode, auto-complete (and bunch of lesser-known packages that copied code from them) all try to use overlays for this, and that's probably not the best thing.

We have narrowing and invisible text properties - these provide a way to hide a portion of the buffer.
We have overlays - these provide a way to replace a portion of the buffer with something else.
But we seem to miss the capability to reliably show stuff that isn't actually in the buffer.

> In any case, an overlay can have a 'keymap'
> property, where you could perhaps redefine what C-f, C-b, and perhaps
> some other relevant movement commands do.  Did you try that?

Yes. Keymap is only used when front-advance is nil and rear-advance is t, which coincidentally is the only combination that causes typed characters to be "hidden" by the overlay. (perhaps I am doing something incorrectly, however)

But even if I could override C-f and some other keys, that would still be only a half-solution - people might bind forward-char and backward-char to different keys, or they might be using entirely different methods of moving around the buffer (for example I am using avy-goto-char often). I don't think there is a way to handle all such cases by simply overriding the keymap.

-- 
Best regards,
Platon Pronko
PGP 2A62D77A7A2CB94E