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

[Platon Pronko]

On 2023-04-08 13:46, Ash wrote:
> https://github.com/emacs-lsp/lsp-mode/issues/3263 is a bug in lsp-mode (emacs's
> own eglot has the same bug as far as I can tell) that appears to boil down to
> the behavior of emacs overlays and after-string. That is, if your buffer looks
> like
>
> let my_value{: Vec<i32>} = vec![0, 1, 2];
>
> (where the curly braces indicate the after-string property of an
> overlay), you need to put your cursor *after* the overlay to
> insert text at the end of the variable name, which comes *before*
> it, and it's impossible to put your cursor immediately between
> the overlay and the preceding text. I assume the behavior the
> user desires is that you can put your cursor either immediately
> before or immediately after the overlay and insert text, and that
> pressing the left/right arrow would move you over the overlay but
> leave the actual position of point unchahnged.
>
> My suspicion is that this isn't fixable just by setting the right text/overlay
> properties, since both the cursor locations immediately before and after the
> overlay actually correspond to the same location in the underlying string. But
> I'm not good at text property arcana. Any advice?

Github issue has some suggestion about how it could possibly be done, and the 
poster
rightfully notes that the solution is nasty (essentially catching the event of 
cursor
moving 1 char forward, tweaking overlay properties and resetting the cursor 
back).

Does it actually make any sense to put the cursor right after the overlay?

In my opinion the easier solution would be to always put it before the overlay 
- this way
when the text is typed it is inserted right before the cursor, not somewhere 
else.

However there are problems with that as well, because right now there is no 
correct way to
set cursor position when near the zero-width overlay
(see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62540).

--
Best regards,
Platon Pronko
PGP 2A62D77A7A2CB94E