Re: Toning down font-lock

[Augusto Stoffel]

On Mon,  7 Mar 2022 at 11:10, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> [ FWIW, I use a "theme" where most font-lock faces use the same colors as
>   the default face ;-)
>   IOW: black-on-white for most faces, grey-on-white for comments,
>   different fonts for strings and keywords, bold for function
>   names, ...  ]
>
>> I'm also wondering if there is a more fine-grained mechanism to pick and
>> choose font-lock rules.
>
> No, we only have this notion of "level" which is not very useful or even
> well defined (does it relate to CPU cost, or gaudiness, or ...).
>
>> I guess not, so should there be one?
>
> Yes.  But I don't think it makes much sense to try and retro-fit into
> the current `font-lock-keywords` system, which is already too complex
> (yet not flexible enough) for its own good.

Okay, so I was sketching something like “gitignore for font lock”.  You
can remove a keyword by naming a symbol that appears anywhere in it (say
a face name) or using some fancier selectors.  Or you can cancel a
previous removal by prepending the selector with an exclamation mark.

This is how a user configuration could look like.  I hope you can get
the idea.

```
(font-lock-ignore-mode)

(setq font-lock-ignore-rules
      '((prog-mode
         "^font-lock-.*-face$" ;; Remove all font lock except strings
                               ;; and comments by default.
         ! help-echo) ;; Whatever highlight has a help message must be
                      ;; important.
        (emacs-lisp-mode
         ! (matching ";;;###autoload") ;; Keep highlighting of autoload cookies
         lisp--match-hidden-arg) ;; Out of perversity, remove this keyword
        (makefile-mode
         ! *))) ;; Makefile is chaotic, I need emotional support (bring
                ;; back everything).
```

And here is the code.  It's too much of a hack for core, but maybe
sufficiently useful for a package?

font-lock-ignore.el
Description: application/emacs-lisp

> I think we should instead introduce a brand new "syntax".  This new
> syntax should indeed include a way to give names to some "rules" (or
> groups of rules) so they can be enabled/disabled by the user.

Okay, but this doesn't seem that hard to retrofit into the current
system.  We could allow a keyword-pair :name SOMETHING in the elements
of `font-lock-keywords' (this metadata can be discarded upon
compilation, so not many changes are needed in font-lock.el).  Then the
user can enable or disable things by name.

> Whoever designs this new set of rules would do well to study other
> editors's approaches to this problem to benefit from some of the
> advantages of the solutions they chose.

This is wise.