emacs-devel
[Top][All Lists]
Advanced

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

Re: Major modes using `widen' is a good, even essential, programming pra


From: Eli Zaretskii
Subject: Re: Major modes using `widen' is a good, even essential, programming practice.
Date: Mon, 08 Aug 2022 14:30:30 +0300

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  gregory@heytings.org,  emacs-devel@gnu.org
> Date: Mon, 08 Aug 2022 05:25:21 -0400
> 
> > The intent is clearly that fontifications don't look far beyond these
> > two points, because otherwise the whole design of jit-lock and its
> > invocations during redisplay is basically thrown out the window.
> 
> Usually, font-lock rules don't look before BOL or after EOL, indeed,

But BOL and EOL could also be very far away, so that, too, needs some
reasonable limit.

> *except* via `syntax-ppss` which does look at all the text from BOB
> to point.  To make up for that, `syntax-ppss` relies heavily on caching,
> so that it *usually* doesn't need to look very far at all (and if
> there's no `syntax-propertize-function`, it's usually quite fast
> because it's fully coded in C).
> 
> For GB-sized buffers, even the fast C code of `syntax-ppss` incurs
> a significant delay in the "unusual" case, so have various options:

I reported this for a 18MB single-line file, which is way below the GB
bar.

The problem is that the initial full scan can take "forever" in those
files, and that basically means we cannot edit such files in practice.
So if you dislike the current solution of locked narrowing, how about
making syntax-ppss work in chunks (perhaps from an idle timer?), after
initially scanning only the first small portion of the file.  The goal
is to have the file displayed quickly enough, and thereafter complete
the scan when possible.



reply via email to

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