[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stephen Leake
Subject: Re: [SPAM UNSURE] Re: How to add pseudo vector types
Date: Wed, 21 Jul 2021 09:54:45 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt)

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 7/20/21 12:32 PM, Stephen Leake wrote:
>> Computing fontification and indentation must be synchronous.
> Must?  What makes you say that?

Otherwise the results cannot be applied to the buffer, in general.

>> Except that the results will not be useful, since they won't apply to
>> the original buffer if it is changed.
> Then you will send the additional changes and wait.

It is that "wait" that makes it synchronous.

Note that synchronous is not the same as single-thread; mulitple threads
can be used, as long as the main thread waits for the parse results.

But synchronous is also not the same as requiring the buffer text to be
read-only while the parser is running, which is an additional
requirement if the parser is reading the buffer text directly.

> TS is an incremental parser, so the work it will have done
> incorporating part of the changes will not be wasted.

Not guarranteed if the new changes are before some of the old ones, and
TS has no support for interrupting a parse to add more changes.

> Concrete example: if you have a bit of elisp that runs for .5s to make
> modifications to the buffer, then press "indent", and only then do you
> send changes to TS and wait for the response synchronously, then you
> will wait for .5s + time to incorporate all changes. If you start
> processing the changes in parallel as they are made by the Elisp code,
> then you will only wait for .5s + time to incorporate only the changes
> that had not been processed yet.

It might be possible to implement the incremental parse algorithm so it can
accept changes after the parse starts. One requirement would be that the
new changes must be after the current parse point, which is a race

In your example, "indent" will go back to the first edit point to compute
the indent there; that is pretty much guarranteed to be before the
current parse point, which will be on one of the later changes.

Neither TS nor wisi support that; both have a separate Edit_Tree step
that applies all the changes to the parse tree before Parse is called. It
might be possible to integrate Edit_Tree into Parse, so that changes are
only applied when they are actually needed. But Edit_Tree and Parse are
already very complicated; keeping them separate is a good thing for
correctness and debugging.

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. Depending on the details of the changes, that might or might
not be wasted time; if we are on battery power (or worried about carbon
footprint), this might be a bad idea.

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.

-- Stephe

reply via email to

[Prev in Thread] Current Thread [Next in Thread]