Re: [SPAM UNSURE] Re: How to add pseudo vector types

[Clément Pit-Claudel]

On 7/21/21 3:49 PM, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Wed, 21 Jul 2021 13:12:16 -0400
>>
>> On 7/21/21 12:54 PM, Stephen Leake wrote:
>>> Hmm. Perhaps you are not talking about interrupting the parse; you are
>>> assuming that the parse for each change completes before the next change
>>> arrives.
>>
>> Neither of these.  I'm assuming that you open a file, launch a parse, batch 
>> up changes until that first parse completes, then launch a second parse, 
>> during which additional changes are batched up, then launch a third parse, 
>> etc.
> 
> But how would the "launched parse" access the buffer text if it runs
> in parallel to normal editing?  We've discussed the difficulties with
> that, and you seem to ignore them here?

Lots of magic handwaving: IOW, I don't have a solution, just a general hope 
that minimal synchronization and decent error recovery would help (for example, 
maybe it's enough to synchronize only when TS requires a chunk of memory).  But 
for the discussion above, Stefan's copying solution works fine.

>> Any time you actually need the info (for navigating, or for fontification, 
>> or…) then you either use the last parse if it was recent enough, or (more 
>> likely) you block until you can complete a synchronous parse.
> 
> Which means the results will many times be slightly wrong, because the
> parse info you use is outdated?

Maybe.  In practice if the delay between requesting the info and getting it is 
perceptible, then displaying outdated info is better than freezing until you 
get up-to-date info, no?  Either you're getting info so fast that the user 
doesn't realize that you're outdated by 1ms; or you're getting info so slowly 
that the user realizes that you're running one second behind — but it's much 
better than freezing for one second.

Less relevant details below:

This is a problem we have all the time with Flycheck btw: you send the text of 
the buffer to a compiler, it returns 3 seconds later, and you want to display 
errors as reported by the compiler.  By the time we get errors to display, the 
locations they come with are outdated.  We don't have a good solution.

Visual Studio in the old days had a really beautiful solution for this.  There 
was a (basically) free API you could call to snapshot a buffer at a point in 
time; then there was a function that translated positions in that snapshot to 
position in the current buffer (think of it as magically putting a marker into 
the past buffer when the snapshot was taken, and then querying its current 
position).  So positions returned by the compiler or any other tools were still 
relevant if they referred to a three-seconds old buffer, since you could 
translate them to the current buffer.

Clément.