[undo] can't undo some threaded commands

[midichef]

Small description
After a pasting into cells or rows using syspaste-*, undo does not restore the original value of the cell.

Steps to reproduce with sample data and a .vd
Starting with this tsv sheet:

cells
first
second

hit zY on the cell that contains"first", then j and then zP

cells
first
first

then hit U, and no undo happens. Instead there is a message: nothing to undo on current sheet.

To trigger the bug, syspaste-cells must be done manually. If it's done inside -p script.vdj, then undo-last works as expected.

Additional context
saul.pw/VisiData v3.1dev

The behavior started with a9e4e05 and its parent commit.

I've looked into the undo code a bit. The problem is that when syspaste-* runs addUndo(), vd.activeCommand is None, so the function returns without adding to r.undofuncs. I'm not sure what the fix should be.

[midichef]

The problem is a race condition in basesheet.py:

visidata/visidata/basesheet.py

Line 211 in 74c6eb2

escaped = super().execCommand2(cmd, vdglobals=vdglobals)

visidata/visidata/basesheet.py

Line 219 in 74c6eb2

vd.callNoExceptions(vd.cmdlog.afterExecSheet, vd.activeSheet, escaped, err)

The events happen in this order:

1. execCommand() runs execCommand2(), which starts pasteFromClipboard() in its own thread.

2. pasteFromClipboard() starts. It will eventually look at vd.activeCommand, but not yet. It runs a command to check the clipboard, but that takes a while to finish, so it is paused.

3. execCommand() resumes. It runs afterExecSheet() which changes vd.activeCommand to None.

4. pasteFromClipboard() resumes. When it tries to make its undo functions, in addUndo(), it sees the wrong new value of vd.activeCommand, so it does not add its undo functions to the command log sheet.

5. Because there are no undo functions, when I do undo-last, it fails.

As a confirmation that this is what's happening, undo is fixed when I remove the @asyncthread decorator from pasteFromClipboard().

A fix would be to make sure afterExecSheet() doesn't run until the threaded command finishes. But at the moment I'm not sure how to do that.

[midichef]

A fix would be to make sure afterExecSheet() doesn't run until the threaded command finishes. But at the moment I'm not sure how to do that.

On looking into this deeper, I realized such a fix was not workable.

There's a better way to fix this. Instead of having only 1 activeCommand for all the threads, give each thread its own activeCommand. I'll submit a PR for that.