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

[Ash]

On Sat, Apr 8, 2023, at 3:10 AM, Platon Pronko wrote:
> 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

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.