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

[Platon Pronko]

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.

As I understand it, no combination of front-advance and rear-advance will allow 
overlay to stay in-place if something is typed at start point. Example:

<cursor>{hint} => type A => {hint}A<cursor>

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

> And that is even before considering whether overlays are the best
> infrastructure for implementing this stuff in Emacs.

It definitely feels they are not :) Even the name says "overlay", while they 
are overlaying nothing in this case. What can be used instead?