bug#23465: 25.0.93; `lambda' after hash-quote not highlighted as keyword

[Stefan Monnier]

> Emacs has for a long time highlighted "keywords" (taken with a grain of
> salt) like "progn", "if", "when", "and", "or" etc.  In other words, the core
> functions used when writing elisp.

This is obviously a question of opinion, but the way I look at it, it
was a manually-managed approximation of "the set of macros/specialforms".
So yes, it included (usually) less than the new code, but it included
a good bit more than "the core" (for my own opinion of what is "core",
clearly).

> However, now Emacs also highlights *all* macros when they are used. In some
> cases, like in "define-lex-block-type-analyzer", the keyword face is used
> so much that the visual cues it normally provides are lost.

Hmm... I don't understand the problem you're referring to.

I looked at the uses of define-lex-block-type-analyzer I could
find in Emacs's trunk and they look OK to me.  I also looked at the
definition of define-lex-block-type-analyzer and its highlighting also
looked fine to me.

> In this case, it would be better to use a different face for the user
> macros.  One candidate would be font-lock-preprocessor-face.

I think you expect something different, indeed.  Personally I don't care
who/where the macro is defined.  I only care about the fact that the
evaluation rules will likely not be the same as a function call.

IOW I do find some of the new highlighting distracting, but only for
those macros which behave just like functions (i.e. typically macros
which would better be defined with defsubst or define-inline).

> Anyway, we're striding away from the subject here. I'll commit the fix for
> the "lambda" problem on the master branch and leave it broken on emacs-25.

Not sure I like this fix: it causes the `if` of #'(if bar baz) to be
highlighted even though it's not a special form nor a macro in
that position.


        Stefan