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.