unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@IRO.UMontreal.CA>,
	"'Vitalie Spinu'" <spinuvit@gmail.com>
Cc: emacs-devel@gnu.org
Subject: RE: font-lock-maximum-decoration and how to make a default font-locklower than maximal?
Date: Sun, 26 Aug 2012 11:26:55 -0700	[thread overview]
Message-ID: <D6A40EC7ADEB44058D324B5905EECDC6@us.oracle.com> (raw)
In-Reply-To: <jwvmx1oma85.fsf-monnier+emacs@gnu.org>

> > For example, assume you are developing X-mode and some 
> > users would like to have functions + numbers + other stuff
> > highlighted, but you don't want to activate those by default.
> > So you can add font-lock keyword levels (2, 3, 4 etc) to
> > accommodate this preference, but want to set the default to 2.
> 
> I hate font-lock-maximum-decoration's notion of "levels" because
> there is no such neat line.  Some users will care about one
> particular detail, others about an other.  So please don't use
> font-lock's levels for that fine-grained control.  Instead just
> introduce new config vars specific to your major mode.

You are throwing out the baby with the bath water.
And you are missing the point about font-lock "levels".

Font-lock levels are not just for users to _customize_ decoration for a
particular mode, in a single, fixed way.

Font-lock levels let users easily (e.g., using a cycle command or picking a
"level" from a menu, as in `font-menus.el' from FJ Wright) switch to a different
kind of highlighting.

Those kinds are called "levels" today, but you need not (and probably should
not) think of them as such.  "Level" here is a misnomer.

So-called "levels" are just different highlighting patterns.  These patterns
might or might not reflect different highlighting degrees ("levels"), however
you might want to imagine such leveling.  There is no need to think in terms of
degree at all.  Think "different", not "more" or "less".

Whether users should be able to easily customize the "levels" available for a
given mode is a good question.  I certainly am all for that possibility.

By all means, let users customize what the font-locking choices are for a given
mode, and how many choices there are.  Go for it.  And if the doc and names used
for this customization emphasize that these are just arbitrary sets of font-lock
appearances, rather than "levels", so much the better.

But please do not take away the ability to interactively switch among such
highlighting choices, which is provided by today's "levels" mechanism (with a
little help from `font-menus.el' etc.).

The facts that (1) most Emacs modes do not currently provide more than one
"level" by default, and that (2) many users are unaware that they can choose a
highlighting pattern ("level") when such a choice does exist, is not a reason
for tossing the mechanism.  (Choose = customize once and for all or switch
patterns interactively.)

Rather, those facts are reasons for Emacs Dev to (a) offer different predefined
highlighting choices for more modes, (b) advertise the feature more, and (c)
provide better interactivity (switching among choices) out of the box.




      reply	other threads:[~2012-08-26 18:26 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-17 12:29 font-lock-maximum-decoration and how to make a default font-lock lower than maximal? Vitalie Spinu
2012-08-17 14:29 ` Eli Zaretskii
2012-08-17 14:42   ` Vitalie Spinu
2012-08-17 15:57     ` font-lock-maximum-decoration and how to make a defaultfont-lock " Drew Adams
2012-08-17 19:49       ` font-lock-maximum-decoration should be 2 by default? Vitalie Spinu
2012-08-17 20:26         ` Eli Zaretskii
2012-08-17 20:53           ` Drew Adams
2012-08-18  6:59             ` Eli Zaretskii
2012-08-19  2:32               ` Jason Rumney
2012-08-19  3:13                 ` Drew Adams
2012-08-19  3:34                   ` Jason Rumney
2012-08-19  4:39                     ` Drew Adams
2012-08-19 10:50                     ` Vitalie Spinu
2012-08-19 16:46                   ` Eli Zaretskii
2012-08-19 17:33                     ` Drew Adams
2012-08-19 10:34                 ` Andreas Schwab
2012-08-19 16:48                   ` Eli Zaretskii
2012-08-17 20:50         ` Drew Adams
2012-08-17 22:47           ` Vitalie Spinu
2012-08-18  7:03             ` Eli Zaretskii
2012-08-18 10:10             ` Vitalie Spinu
2012-08-21 17:31               ` Stefan Monnier
2012-08-22 16:50                 ` Vitalie Spinu
2012-08-26 18:27                 ` Drew Adams
2012-08-18  5:10         ` Stephen J. Turnbull
2012-08-18 10:03           ` Vitalie Spinu
2012-08-19 11:10             ` Stephen J. Turnbull
2012-08-19 11:47               ` Vitalie Spinu
2012-08-19 13:23                 ` Stephen J. Turnbull
2012-08-17 17:36     ` font-lock-maximum-decoration and how to make a default font-lock lower than maximal? Eli Zaretskii
2012-08-21 17:24 ` Stefan Monnier
2012-08-26 18:26   ` Drew Adams [this message]

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D6A40EC7ADEB44058D324B5905EECDC6@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    --cc=spinuvit@gmail.com \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).