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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 9 Aug 2022 17:38:22 +0300
> Cc: monnier@iro.umontreal.ca, acm@muc.de, gregory@heytings.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> >    emacs -Q
> >    M-: (setq long-line-threshold nil) RET
> >    M-: (setq syntax-wholeline-max most-positive-fixnum) RET
> > 
> > visiting dictionary.json, a 19MB single-line file, takes "forever" (I
> > killed it after 20 minutes) before it shows anything in the window.
> > And since both variables use "arbitrary restrictions", and both can
> > cause inaccurate/incorrect/wrong/buggy/<your euphemism here>
> > fontifications, my proposal above was to do something smarter.
> 
> I never recommended you to change any of those vars.

Then I don't really understand what is it that you are arguing about.

My proposal to Stefan was to make syntax-ppss and friends less of a
burden _instead_ of the currently implemented "arbitrary restrictions"
that he doesn't like.  You seemed to have contradicted my proposal by
saying that the file is already displayed quickly enough, but that
only happens _with_ those "arbitrary restrictions".

So what is your point here?

> >> What's going to happen then, if the timer hasn't fired yet?
> > 
> > We should process a relatively small portion of the buffer around the
> > new position of point.
> 
> To speed up the jump to a far distant part of the buffer after doing an 
> edit "here", the timer would have to parse the whole buffer between here 
> and there. Or most of it.

I didn't say it should be done from a timer in this case.  And it
shouldn't.

> > Not surprisingly, this is precisely how jit-lock is supposed to work,
> > if only the stuff called through fontification-functions obeyed the
> > region which it was told to process.
> 
> If you concerned with the speed of font-lock itself (and not with the 
> speed of syntax-ppss cache maintenance which we've talked about before), 

I'm concerned with both, because font-lock typically calls syntax-ppss
in many modes.

> and in your case it might be justified, given the unoptimized build, 
> then using something like stealth fontifications could indeed speed up 
> C-v/M-v. Not M->, though.

I'm a happy user of stealth fontification in my production sessions,
where I run fully optimized builds.