Re: "Font-lock is limited to text matching" is a myth

[Stefan Monnier]

>> I'm not too fond of cc-mode's indentation code and configuration,
>> actually, so I don't mind if js2-mode doesn't share anything with it
>> (tho I won't oppose a change in this respect either).

> I'd like to hear more about the objections.  I realize it's horribly
> complex, but I've looked at other configurable indenters and they
> always wind up being too complex for most users as well -- gigantic
> manuals, custom minilanguages, the works.

I have two reasons not to like it: the horribly complex indentation
code, and the horribly complex compilation and configuration "stuff"
(very non-standard with very dubious benefits).
But I don't claim there's something better out there to fulfill the
same requirements.

> Yes.  Eclipse has a fast, inaccurate parser that runs inline as you type,
> and a slow, accurate one that lags behind by a few hundred ms.  (They
> handle name resolution this way as well, except the fast one runs with
> the slow parser, and the slow one can take minutes to hours.)

> Eclipse uses the fast/inaccurate parser for both fontification and
> indentation.  The slower parser is used when (for instance) you want to
> reformat a block of code -- something like a cross between indent-region
> and fill-region for source code.  I'm not an Eclipse user myself, so I'm
> not familiar with all the ins and outs, but this is the basic approach they
> take.

Thanks.  That makes a lot of sense.

>> [ Putting on my functional programmer hat here. ]
>> All you're saying here is that your languages have too many concepts.
> Yes, well, of course.  But they're not _my_ languages now, are they?

They're yours in the sense that you care for them and (presumably)
use them.

>> [ Putting on my Emacs maintainer hat again. ]
>> highlighting should be about helping the user understand his code:
>> highlighting every character with a different color is the way to
>> get there.
> I'm not 100% sure I follow this statement.  Do you mean "not the way"?

Yes, the "not" somehow escaped, sorry.

>> You may want to help him find structure (e.g. make
>> function/method declaration stand out), you may want to help him not get
>> confused (highlight strings and comments differently), you may want to
>> attract his attention to weird things (undeclared variables, ...), but
>> I highly doubt that highlighting function parameters differently from
>> local variables will help her in any way.

> We don't know this, and in fact cannot know it a priori, since there are new
> languages appearing all the time.  And templates with mixed languages
> complicate things further.

In Emacs we generally work on a need basis (pretty much like eXtreme
Programming advocates, although the relationship doesn't go much
further I believe).  It's very easy for a major mode to add its own face
if the needs comes up.  Until now, I haven't come across any language
where highlighting function parameters specially would be useful.

> I think it's best not to be in the business of dictating or even
> advising taste.  We should focus on making things flexible enough for
> people to make the distinctions they wish to make.

We'll have to agree to disagree on this one.

>> > Vf) No font-lock interface for setting exact style runs
>> [...]
>> > The problem is that I need a way, in a given font-lock redisplay, to
>> > say "highlight the region from X to Y with text properties {Z}".
>> I'm not sure I understand the problem.  What's wrong with
>> put-text-property?
> font-lock biffs my properties.

That's another problem.  If you do it from font-lock-keywords, then it
works just fine.

>> Just place in font-lock-keywords a MATCHER that is a function whose code
>> walks the list of your "runs" (checking which of your runs are within
>> (point) and LIMIT) and uses add-text-properties on them; and finally
>> returns nil.
> This is different from what Daniel advised, and neither approach is
> very well documented (if at all).  I will try them both and report
> back when I can.

I believe it is the same as what Daniel advised, actually.  It's not
well documented simply because there's not much to document: the MATCHER
is a function so it can do anything it wants.

>> > Vg) Lack of differentiation between mode- and minor-mode styles
>> [...]
>> > As far as I can tell, the officially supported mechanism for
>> > adding additional font-lock patterns is `font-lock-add-keywords'.
>> > This either appends or prepends the keywords to the defaults.
>> Yes, this sucks.  It should be replaced by a more declarative interface.

> A simple workaround for now might be to keep pointers to the originals
> and the extras in an alist that remembers who added which keywords.

If you assume that there are no coincidences (same keywords added by
different (minor)modes), then as long as each (minor)mode adds and
removes his own, then it's not too terrible.  But, yes, occasionally
it's a pain (when you want to reconstruct the whole thing for one
reason or another).  Mostly it means that you have to remember what
you've added so that you can properly remove it.


        Stefan