From: Augusto Stoffel <arstoffel@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Toning down font-lock
Date: Mon, 07 Mar 2022 20:25:17 +0100 [thread overview]
Message-ID: <87czixa7ky.fsf@gmail.com> (raw)
In-Reply-To: <jwv7d95n48o.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Mon, 07 Mar 2022 11:10:01 -0500")
[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]
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?
[-- Attachment #2: font-lock-ignore.el --]
[-- Type: application/emacs-lisp, Size: 5427 bytes --]
[-- Attachment #3: Type: text/plain, Size: 715 bytes --]
> 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.
next prev parent reply other threads:[~2022-03-07 19:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-05 18:03 Toning down font-lock Augusto Stoffel
2022-03-07 16:10 ` Stefan Monnier
2022-03-07 19:25 ` Augusto Stoffel [this message]
2022-03-07 23:55 ` Stefan Monnier
2022-03-08 11:50 ` Augusto Stoffel
2022-03-08 15:18 ` Stefan Monnier
2022-03-10 7:42 ` Augusto Stoffel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87czixa7ky.fsf@gmail.com \
--to=arstoffel@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.