[Top][All Lists]

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

Re: cc-mode fontification feels random

From: João Távora
Subject: Re: cc-mode fontification feels random
Date: Sun, 13 Jun 2021 11:06:55 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

martin rudalics <rudalics@gmx.at> writes:

> I admit that this probably meets most users' intentions.  What I do not
> understand about its implementation is that if `jit-lock-contextually'
> is t (as it is usually set by `jit-lock-register'), you unconditionally
> add the antiblink mechanism to `post-command-hook' which IIUC causes a
> `syntax-ppss' call unconditionally getting run for each command even
> when `jit-lock-antiblink-grace' is nil.  Is that perception correct?  If
> so, I think that you should not do that.p

Oof, I don't have the implementation of it in L1 cache right now.  May
be.  May be not.  The implementation was reviewed closely at the time,
including some extensive performance tests in xdisp.c, coordinated by

But looking summarily at the code it doesn't seem to be
"unconditionally" at all.  There are four different conditions that have
to be cumulatively verified before that invocation of syntax-ppss takes
place.  And I seem to remember that syntax-ppss isn't very expensive

>> Regardless, I would file a bug if I saw that behaviour :-) ,
> ... even with `open-paren-in-column-0-is-defun-start' non-nil?

Depends on whether parts of Emacs's _require_ it to be non-nil.

> But `open-paren-in-column-0-is-defun-start' is a customizable variable.
> Which means that a user should be able to use it to control the behavior
> of Emacs in this regard.  And it is t by default for no obvious
> reason.

I didn't know it was customizbale (or rather didn't bother to check, I
admit).  But again, I seem to remember that customizing it back to nil
wasn't an option and that Emacs would break.  Maybe that has changed?
Is it really truly optional?


reply via email to

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