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

[Alan Mackenzie]

Hello, Eli.

On Sun, Aug 07, 2022 at 20:23:21 +0300, Eli Zaretskii wrote:
> > Date: Sun, 7 Aug 2022 17:01:09 +0000
> > Cc: gregory@heytings.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > Consider the second jit-lock chunk
> > > > at the beginning of xdisp.c.  Fontifying that chunk involves looking
> > > > back 1500 characters before BEG to see that it needs
> > > > font-lock-comment-face.  You might argue that that information will be
> > > > in a cache anyway, but that's not dependable.

> > > Either in the cache or in the buffer: the previous chunk was
> > > fontified, so its end has the font-lock-comment-face.  So you know.

> > No, you don't.  The buffer might be being opened by desktop in a large
> > comment in the middle of the file.

> You've changed the scenario, yes?

Yes.  We've got to deal with all scenarios, preferably without
special-caseing special cases.

> > What jit-lock/font-lock actually do at the moment is to widen, then use
> > syntax-ppss, i.e. in effect scan from BOB.

> Yes, and that's SLOOOWWWW!

On my machine, with an optimised build, it takes just under 20 ms to
parse-partial-sexp over xdisp.c (not counting any redisplay at the end).
I don't understand any more than Dmitry does, why your unoptimised build
is taking 25 times as long.

> > > > Also, the (BEG END) region will typically get rounded up to whole
> > > > lines, again "violating" that chunk.

> > > That's a far cry from going to BOB.  And if you ask nicely, we
> > > could arrange that jit-lock calls you only on line boundaries
> > > (unless lines are longer than some reasonable value).

> > The search for line boundaries is done by font-lock.el.

> I don't trust it to DTRT when lines are very long.

I think I raised the topic a few days ago of font-lock expanding regions
to whole lines.  Maybe we shouldn't do it for long lines.  We'd need
something in its place, though.

> > > > In principle, font-lock needs to look outside of (BEG END).

> > > No, it doesn't.  A string cannot begin before a beginning of a
> > > function, for example.  And if you need to go too far, just give up
> > > and blame the user who writes such code.  It is much better than
> > > letting every use of CC Mode wait because once in a blue moon someone
> > > could have a very long string.

> > That "needing to go too far" is an instantaneous jump, not a scanning.

> Please tell that to someone who doesn't edit C sources as frequently
> as I do.

Are you saying that long strings and long comments cause a particular
slowdown in C Mode, not seen when strings and comments are all short?

> > The string start will be in a parse-partial-sexp result somewhere.
> > Sometimes people write long strings.  They certainly write long comments.

> Why do I have top suffer every day just because someone, somewhere,
> might do that?  I'd rather we "punish" those few people who do it
> (rarely).

I don't think we should punish people who write comments.  I'm thinking
of Gerd M., who was likely the writer of the comment at the beginning of
xdisp.c.

-- 
Alan Mackenzie (Nuremberg, Germany).