Async and reactive bugs after annotation updates

[elmisback]

While testing the system for the video, I saw major issues with async updates and hacked a temporary fix into the updateAnnotation function (after an async edit completes, we completely ignore the value in this.annotations and overwrite with our own value)

magic-markup/vscode-extension/src/AnnotationTracker.ts

Line 629 in 99afa08

public async updateAnnotation(document: vscode.TextDocument, updatedAnnotation: Annotation): Promise<void> {

. This probably risks losing data if a bad sequence of async updates occurs.

Instead, we should process updates synchronously. This may require forming an update queue or throwing away updates that occur when the system is busy.

There's a separate issue of many update calls being triggered after a single user action due to reactive updating. This should be documented on this issue. Ideally, the logic should be carefully re-coded to limit reactions to cases where they are necessary.

[elmisback]

In general, I am not a fan of the object-oriented architecture that has evolved for this system, I think it's super gross and I would like to refactor into testable functions that take in and output data and avoid mutating objects.

[elmisback]

The fortunate part here is that the system is at least somewhat modular, so I may be able to focus on just refactoring AnnotationTracker as an equivalent functional module first, then on making it synchronous and cleaning up.

[elmisback]

I've made this more testable.

After making it fully synchronous by just writing to the file system, I'm realizing this has been overcomplicated.

All the reactive update problems come from document modifications via setText (anchor text set). We're taking on too much by trying to keep these edits synchronized with updates to the annotation file. It's also bad to write to the file system, since the user doesn't expect the file to be written unless they save the file, and the editor buffer can fall out of date.

I'm going to try handling setText requests through a separate method that just runs an edit on the buffer (no annotation update, we'll let the edit handler solve that). We don't need to support more than that, tools can handle synchronizing rendering with document modifications if they want to take on writing to the document. If we collect many examples of tools struggling with this, we can make a helper for doing it in the system, but let's not optimize prematurely.

#37 and other issues are higher priority than getting this 100% right, async document writes that are interleaved with user edits are a very niche use case.