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

[Yuri Khan]

On Tue, 11 Apr 2023 at 15:49, Platon Pronko <platon7pronko@gmail.com> wrote:

> I'm talking more about the user intention, before he actually types anything, 
> and consequently the confusion he will temporarily experience when he will 
> try to execute this intention. We here in Emacs mailing list understand the 
> internals quite well and thus can understand that the overlay is zero-width 
> and cursor position is actually the same on both sides. Less-enlightened user 
> won't - for him the inlay is something tangible, present in the buffer the 
> same way as the characters are present in the buffer.

Then the less-enlightened user is screwed, because treating the inlay
text as ordinary code may teach them wrong syntax.

Example 1: C++ does not have named arguments, but inlays will still
show them. And, presumably, not in /* comment markers */.

Example 2: In Python, named arguments are allowed only after all the
positional arguments. If a user sees test(a1=42) and does not realize
“a1=” is an inlay, they may try to prepend an explicitly named a0=3.14
argument and be stumped at a syntax error message for “test(a0=3.14,
42)”.


> And in the discussed example the user can have two different intentions:
>
> […]
>
> Intention 2: prepending another argument. In this case he will want to 
> position the cursor before the overlay:
>
> test(<cursor>a1=42)

Yes, but in order to consistently act on this intention, the editor
must insert the argument separator as soon as a character is inserted
before the inlay, and also be prepared to deal with the user typing it
in manually after the argument value.

> // User tries to type "a0=1," (let's imagine there was such an argument)
> test(a<cursor>a1=42)
> // More typing
> test(a0=1,<cursor>a1=42)


All that said, I think it may be considered an argument in favor of
suppressing the inlay when the point is adjacent to it, the same way
prettify-symbols-unprettify-at-point does for prettify-symbols-mode.