Re: Advising in cc-awk.el and namespace

[Stefan Monnier]

> >Regarding c-awk-advise-fl-for-awk-region:
> 
> A quick summary for others:  c-awk-advise-fl-for-awk-region is a macro in
> cc-awk.el which advises four font-lock functions (e.g.
> font-lock-after-change-function) which get called as
> after-change-functions.  The advice changes the BEGIN and END arguments
> to encompass the complete region which needs refontifying.  This is done
> by syntactically analysing the AWK mode buffer.

In Emacs-21, you should be able to use font-lock-multiline (the variable
or the text-property) to get this effect.

> >It would really be helpful if package maintainers could tell us when
> >they need an `advice'.  It's generally a sign of a shortcoming in the
> >basic functionality and so we need to know about it.
> 
> I posted  "Subject: Font-lock: Major mode should be able to specify
> region to fontify." in gnu.emacs.bug on 10 May 2002 21:31:03 +0200.  This
> post contained tentative patches for font-lock.el, jit-lock.el and
> lazy-lock.el.   It didn't spark off much discussion.

I hereby apologize for complaining when the fault was mine: I completely
missed it (I normally read gnu.emacs.bug carefully, especially when there's
`font-lock' in the subject, so I hope I was victim of nntp's unreliability).

> Personally, I dislike the way font-locking is done at the moment.
> jit-lock-mode, though it speeds up the response of Emacs when first
> loading a file, is very wasteful of processor cycles.  On my 166MHz
> machine (OK - but _somebody_'s got to keep pace with Dan J.  :-), if I
> load a large file (say, ..../emacs/src/keyboard.c) wait for jit-lock to
> finish fontifying it in the background, then make a small change near the
> beginning of this file, needlessly refontifying ~320kBytes consumes ~55%
> of the CPU's power for 3½ minutes.

You might want to set jit-lock-stealth-time to nil.

> I have jit-lock-defer-contextually set to t, which is what causes the
> above.  However, if the major mode were to specify the region to
> font-lock, jit-lock deferred "contextual" fontification would never be
> needed.

It is necessary to keep some state (currently it's limited to the
state returned by syntax-ppss) so that you can refontify one
line of a string without having to refontify the whole string
(which might span many lines).  So specifying the region to refontify
(as do font-lock-multiline and your suggested patch) is not sufficient
because it makes Emacs unbearably slow when typing into such a large
region that gets completely refontified each time (the most glaring
example I know of is with smerge-mode when typing into a large
conflict region).

OTOH, there should be a way for the major mode to add some state info
to font-lock when that state cannot be encoded in the output of
`syntax-ppss' (or better yet, a way to add it to syntax-ppss).
In the case of awk, I believe the state can be (and is) made available
in the output of syntax-ppss, so you could use that in your font-lock
settings to know how to fontify part of a string.

It's poorly documented and there's no hard and fast rule of how to do it
(there are several approaches, each with tradeoffs and limitations), so
I'd need to investigate a bit more before telling you how it could work.

> Also, jit-lock sometimes MIS-fontifies code (for example, in Texinfo
> mode, if Auto Fill mode breaks up an @code{...} thing, for example, the
> new line gets the proper face to begin with, but loses it 3 seconds
> later.

I believe it works correctly if you set font-lock-multiline to t (although
there might still be corner cases where it will fail).

> This happens because jit-lock yanks that line from its syntactic
> context before refontifying it.  I'm talking about the jit-lock that was
> shipped with Emacs 21.1.  Sorry if these things have since been fixed.

These are all related to "patterns that span more than one line" which
is generally recognized as a hard problem.


        Stefan


PS: By the way, the comment in cc-fonts.el that says:

  ;; `c-invalid-face-name' is used.  Since font-lock in Emacs expands
  ;; all face names in `font-lock-keywords' as variables we need to have
  ;; a variable for it that resolves to its own name.

is wrong.  It's just that font-lock-keywords specify expressions
(which are passed to `eval') so if you want to specify a face rather
than a variable containing a face you just need to quote the face name.