[Top][All Lists]

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

Re: [Emacs-diffs] emacs-24 d69e9f1: CC Mode: Stop Font Lock forcing font

From: Alan Mackenzie
Subject: Re: [Emacs-diffs] emacs-24 d69e9f1: CC Mode: Stop Font Lock forcing fontification from BOL. Fixes debbugs#19669.
Date: Fri, 20 Mar 2015 21:12:06 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

Hello, Stefan.

On Fri, Mar 20, 2015 at 02:05:48PM -0400, Stefan Monnier wrote:
> >> There's your problem: your current setup needs the starting point to be
> >> either before "union" or after the first open brace.
> >> It breaks down if it's between the two.  That's the problem you need to 
> >> fix.
> > Not really.  CC Mode is quite capable of handling the Font Lock region
> > starting at BOL2.

> You yourself told me that the region had to start after the brace.

In certain circumstances, this is necessary.  When CC Mode sets a
position using font-lock-extend-after-change-region-function, then it is
necessary to start font-locking from that position.  For example, if a
line in a C file looks like:


and you type an "L" before the comma, CC Mode, whilst font-locking, needs
to know whether this identifier is (i) an element of an enum brace list;
(ii) the name of a variable being declared (when the type will have been
on a previous line); (iii) a parameter in a function call; or (iv) (maybe
one or two other things).  It does this by instructing Font Lock to start
its processes from a specific earlier point in the file.

In the case of FOO being inside a brace, without there being any
semicolon before FOO, that position is the beginning of the first
identifier after the brace.  Starting from that position,
c-font-lock-enum-tail will trigger, font-locking FOOL as
font-lock-variable-name-face.  Starting from outside the brace,
c-font-lock-enum-tail will not trigger, leaving FOOL unfontified.

When you, as a user, put point at BOL2 and type M-o M-o, then this will
work too.

Typing in L4, L5, .... triggering after-change fontification is an
example of the first circumstance, where CC Mode sets BO font-lock region
to just after the brace on L2.

> > The problem is, when that starting point needs to be
> > after the brace on L2, Font Lock moves the starting point somewhere
> > else, fouling up the font locking.

> I'm confused: "somewhere else" is typically BOL2.

Yes.  It is in a syntactically different context.

> Here you say this fouls up font-locking, but above you said CC-Mode is
> quite capable of handling a font-lock region starting at BOL2.

See above.  If necessary for its analysis (I'm not sure if it is), CC
Mode would extend the region as required if asked to start fl'ing at

> > One place which is causing me puzzlement is in jit-lock-fontify-now.
> > It's this bit:

> As you know, jit-lock is irrelevant to those kinds of font-lock problems
> (in the sense that it's always possible to trigger the same problems
> without the use of jit-lock, tho it may require some time to figure
> out a triggering sequence).

No, it isn't.  Jit lock is used, and has its imperfections, one of which
I recently reported as a bug and fixed, another of which is causing me
pain and I've asked you for help on.  These problems don't exist in plain
Font Lock mode (with f-l-support-mode nil).

> > The only way `start' can be before `orig-start' is on the first line of
> > the fl region, and start is moved to BOL.  Why is it necessary to go to
> > all the expense of using `run-with-timer' rather than just fixing things
> > inside `jit-lock-fontify-now'?  What is the use case?

> It's explained in the comment.

OK.  I think I've got it now.  jit-lock-fontify-now is expanding
backwards into a region which is already fontified, but for which it
doesn't "have permission", then reapplying face properties which are
already there, then (just in case a face property might have changed)
triggering a whole new expensive redisplay.  To minimise this expense, a
questionable short cut is applied in another function
(font-lock-extend-jit-lock-region-after-change).  It is this short cut
which is causing me the pain.

There's got to be a better way of doing things than this.

The abstract cause of all these difficulties seems to be Font Lock's not
distinguishing between a beginning of region to be used for analysis, and
the beginning of region to which face properties will be applied.

> Which part of the comment don't you understand?

I'm not sure.  I get it now, but it was extremely difficult arriving at
this understanding.  Perhaps if "any part of the buffer prior to that"
had been "the initial part of the first line before `orig-start'", I
would have got it sooner.

> By the time jit-lock is called the redisplay up to orig-start has
> already been done (you can assume it's already drawn on the screen).

>         Stefan

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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