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

[Clément Pit-Claudel]

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.

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.

This helps if you run a slow, blocking operation that edits the buffer.  Not so 
much otherwise, indeed.

> It still means fontification has to wait for the parse to complete
> on all of the changes; it's synchronous in the sense that no user
> actions on the buffer are allowed between the time fontification is
> requested and the time text properties are applied.

Sure, sure; but hopefully that time is shorter than if the parser hadn't 
received a headstart.

Also, note that my original suggestion was mostly about the initial parse:

> I have no idea if it makes sense, but: does the initial parse need to be
synchronous, or could you instead run the parsing in one thread, and the
rest of Emacs in another?

If the initial parse takes a while, you would have no fontification at all for 
the first <n> seconds, if that's what it takes to parse your buffer (font-lock 
wouldn't block, it'd return immediately).

Then, after that initial parse, you would switch to a blocking mode every time 
you need info.  That should be fast if the buffer hasn't changed too much.

If it has changed a lot, then you could revert to a non-blocking parse, while 
abandoning fontification for a little while.