Structural editing hangs in specific cases of unbalanced forms

[ghost]

Works as intended in: v2.0.249
Broken in: v2.0.252

When using Calva and connected to a REPL, if you follow the following steps you will enter a state where you can no longer delete any text, no matter the context (via the delete key, highlighting and replacing with text still works).

To reproduce I do the following:

Connect to a local REPL.
Enter the following form (let [a "123"] a).
Move my cursor to the right of the ] character.
Press backspace until I get (let [a] a).
Highlight and backspace on ].

Now I can no longer delete any other characters in any file. I have to restart/refresh VS code and REPL to regain working functionality.

[PEZ]

Thanks for reporting! I started to look at this, but can't reproduce it. Let's hope we can collect some more clues. If you have the time it would be great if you could run Calva in development mode and see if you can catch this in the debugger. There's info on how to hack on Calva in the wiki.

[PEZ]

Can you see if it seem like Calva is in some infinite loop or something? With #1573 that was the case, but this one sounds a bit different... The way we saw that Calva was stuck in a loop was that one of the cores of the machine got 100% occupied by VS Code.

Also please check if structural editing has stopped working in all files when this happens, or if it is isolated the current one.

[PEZ]

Also please check if structural editing has stopped working in all files when this happens, or if it is isolated the current one.

Sorry, I now also saw:

Now I can no longer delete any other characters in any file.

[PEZ]

I can reproduce a very similar issue now:

With this text (the vertical bar represents the cursor):

(let [a| a)

Pareedit Barf Sexp Forward

The barf happens:

(let [a|) a

But also... BOOM! One CPU core now occupied 100%, structural editing is dead. (Calva pretty much unusable).

[PEZ]

Here's a video of when I reproduce the issue:

calva-cursor-hang-1585.mp4

[PEZ]

It happens when we try to find the opening paren while ”inside” the unbalanced vector. This test exposes it:

        it('Moves backward in balanced list when inner list is unbalanced', () => {
            // https://github.com/BetterThanTomorrow/calva/issues/1585
            const a = docFromTextNotation('(let [a|)');
            const b = docFromTextNotation('(let [|a)');
            const cursor: LispTokenCursor = a.getTokenCursor(a.selectionLeft);
            const result = cursor.backwardListOfType('(');
            expect(cursor.offsetStart).toBe(b.selectionLeft);
            expect(result).toBe(true);
        });

Not sure we're at the root of the problem yet, but certainly closer.

[PEZ]

Fixed it in my branch now. Will create a PR and we can test the VSIX to get a release out quickly. Then I'll continue looking for more places where we should make similar changes as the ones I did to fix this.

[PEZ]

Here's the VSIX: https://19183-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.253-1585-another-unbalance-hang-1b2e276a.vsix