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

[Yuri Khan <yuri.v.khan@gmail.com>]

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.