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

[Ash]

Yeah, I think doing this "right" might require adding a new property to 
overlays/strings (or giving an existing property a new value) to enable this 
behavior and modifying C code. Not sure how viable that is or if it's something 
the devs would want.

On Sun, Apr 9, 2023, at 5:15 AM, Platon Pronko wrote:
> 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
> 
>