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

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

On Mon, 10 Apr 2023 at 12:23, Platon Pronko <platon7pronko@gmail.com> wrote:

> I'll try to do it with bunch of attached images, since it feels that it will be easier to explain. If it's better to use text examples, please tell me, I'll try to reformat them.
>
> The base example is in inlay-base.png image - you can see the inline hint on the second line ("a1 =").
>
> I can position the cursor right before the inline hint (inlay-cursor-before.png), type "41, ", thus adding a new argument before existing one (inlay-cursor-before-result.png).

You’re talking about typing “41, ” as if it were an atomic action. In
some cases (e.g. pasting from clipboard) it could be, but normally
you’ll be inserting characters one by one, and it might be instructive
to look at the buffer contents and expected inlay behavior through the
intermediate stages.

0. Base state:

    def test(a1: Int = 1, a2: Int = 2, a3: Int = 3) {}
    test({a1=}42)

1. You type “4”. Depending on how the editor interprets the insertion
around the inlay:

1a. The editor inserts the digit 4 at the position where the inlay is.
The text is now “test(442)”. Syntactically, you just changed the
argument value, so the inlay should stay before the newly inserted
character.

    def test(a1: Int = 1, a2: Int = 2, a3: Int = 3) {}
    test({a1=}42)

1b. The editor lets you insert the digit 4 before the inlay and
somehow knows it is separate from the “42” that used to be the first
argument. The text is now “test(4█42)” where the block represents some
kind of separator. Likely, this text is invalid syntax, so the inlay
is now technically incorrect.

    def test(a1: Int = 1, a2: Int = 2, a3: Int = 3) {}
    test(4█a1=█42)

2. You type “1”. Same thing as “4” before, only in case 2a the
insertion is no longer adjacent to the inlay so the issue does not
even arise. In case 2b, you now have “test(41█42)” in the buffer and
“test(41█a1=█42)” in the view.

3. You type “,”.

3a. The text is now “test(41,42)” and syntactically it’s a call with
two arguments. The inlay for the first argument stays right after the
opening paren; a new inlay appears after the comma and before the 42.

3b. The text is now syntactically well-formed, so the IDE can update the inlays.

    def test(a1: Int = 1, a2: Int = 2, a3: Int = 3) {}
    test({a1=}41,{a2=}42)

4. You type a space.

For typographical reasons, a well-designed grammar will infer the
space to belong to the separator, not the argument expression. The
inlay will shift after the space.

    def test(a1: Int = 1, a2: Int = 2, a3: Int = 3) {}
    test({a1=}41, {a2=}42)


Basically, after working out the above, my question is: Why is it
important to let the user choose whether to insert newly typed
characters before or after the inlay, if the inlay is going to be
updated and repositioned based on the resulting buffer text?
Alternatively, why is it important to let the user bring the buffer
into an invalid state that may even be unrepresentable in text?