On Sun, Apr 09, 2023 at 08:15:31PM +0800, 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.

What I don't understand is why the overlay doesn't cover the
whole argument value instead of sticking before it. Perhaps
this would ease some of the problems?

Cheers
-- 
t