Updating tickets (#64, #858, #882, #916, #930, #1003, #1004, #937, #965, #966, #967, #968, #1002)

Updating tickets (#156, #747, #805, #806, #972, #194, #274, #335, #339, #375, #603, #610, #641, #642, #664, #665, #684, #743, #744, #759, #760, #762, #796, #800, #809, #820, #853, #856, #857, #884, #893, #900, #902, #916, #917, #953, #969, #990, #1002, #1003, #1004, #1011, #1012, #1044, #40, #119, #121, #129, #130, #145, #160, #244, #264, #265, #387, #392, #433, #454, #459, #463, #479, #508, #524, #529, #536, #589)

Why is this necessary? Reconciling is done in the background.

For large files, reconciling can take a while. If a reconciling operation is ongoing and something happens that makes a new reconciling necessary (i.e. the user has typed something), then there will be an extra delay when the state is inconsistent. If the user keeps typing, there might be another reconcile on top of the previous two, and so on.

If the user ends the typing sequence with a ctrl-space, then the completion will have to wait for all reconcilings to end.

I can easily have two reconcilings queued with shade files.

Making this work properly is not easy, we should probably wait to see what we will do with the whole scanner/parser engine.

Well, if the changes are linear (like in typing and backspacing and typing again), there will be no more than one extra reconcile. Maybe this is good enough? Checking for interrupts in the middle of the parsing might be messy.

And, of course, the updates to the scanner can't be interrupted... but these are fast.

Well, we could just leave the running and ignore the result, while starting a new parse before the old one ends.

I don't think we should do anything right away. We are going to make changes to the scanning/parsing code and it isn't impossible that the issue will become irrelevant.

But we should be aware that this kind of things can happen.