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

[Eli Zaretskii]

> Date: Mon, 10 Apr 2023 13:37:37 +0800
> From: Platon Pronko <platon7pronko@gmail.com>
> 
> On 2023-04-10 13:09, Eli Zaretskii wrote:
> > How is this different from the front-advance and rear-advance
> > arguments you can specify when creating the overlay.
> 
> 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?

> > Did you look at how set-minibuffer-message succeeds in setting the
> > cursor? did you try using the same technique?
> > 
> > Did you try both before-string and after-string overlays?
> > 
> > Did you try non-"empty" overlays, i.e. those whose start and end are
> > not the same buffer position?  They can have before-string and
> > after-string properties as well.
> 
> 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.  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?