[Top][All Lists]

[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: Alan Mackenzie
Subject: Re: Major modes using `widen' is a good, even essential, programming practice.
Date: Sun, 7 Aug 2022 19:20:44 +0000

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

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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