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

[Platon Pronko]

On 2023-04-09 07:06, Ash wrote:
> Yeah, that's my message, hence why I was asking if I was missing something :)
>
> In some cases it makes sense to put the cursor after the overlay; for example, 
> when invoking a function, the overlay can look like
>
> some_function({argument_name: }some_value)
>
> in which case you'd expect to be able to put the cursor after the overlay (to 
> edit the value) and before (to add another argument to the list). Both cursor 
> positions would correspond to the same location, but you're doing something 
> different semantically. So I would expect to be able to type 'another_value, ' 
> before the overlay and 'foo' after and get
>
> some_function(another_value, {argument_name: }foosome_value)
>
> and not
>
> some_function({argument_name: }another_value, foosome_value)
>
> In practice, I think for the existing overlays in rust-analyzer's inlay hints 
> there's a 'preferred' cursor position (start for type annotations, end for 
> param name annotations) where the user will want it 80% of the time, so it 
> could set things up based on that. Might also investigate the nasty solution 
> and see how clean I can get it and see if it's expensive CPU-wise.

I looked at what other IDE is doing (IDEA in my case). They indeed allow the 
cursor to be positioned both before and after the inlay, with added text 
appearing exactly as you described.

I still think that doing this hack with "detect if the cursor moved exactly one 
position forward, tweak overlay, move it back" is horrible. It feels like it might 
be much better if this was handled at much lower level, not at the level of lsp-mode.

--
Best regards,
Platon Pronko
PGP 2A62D77A7A2CB94E