all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Lars Magne Ingebrigtsen'" <larsi@gnus.org>,
	"'Chong Yidong'" <cyd@stupidchicken.com>
Cc: 6935@debbugs.gnu.org
Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration'
Date: Sun, 31 Jul 2011 09:31:54 -0700	[thread overview]
Message-ID: <A22B18C0F274478C87FECC78AB1E0288@us.oracle.com> (raw)
In-Reply-To: <m31ux6336y.fsf@stories.gnus.org>

> > Maybe we should obsolete font-lock-maximum-decoration in 24.2.  The
> > concept of decoration levels hasn't been very useful, and 
> > removing this user option is a good first step to get rid of it.
> 
> Sounds like a good idea to me.  I'll mark this report as "pending".

No; it is a bad idea - on its own, that is, without some subsitute/compensating
feature.

And since when does a "_maybe_ we should" suggestion get translated
automatically into a "pending" change?  AFAICT, "pending" means that a decision
has already been made - it is not a "maybe".  And this topic has not even been
raised yet for discussion (by emacs devel)!

Simply removing this feature, without providing some compensating feature as
Stefan suggested, reduces user control.

If you want to propose something better than the current feature, something
that, as Stefan suggested, provides users _more_ control, then fine.  Propose it
to emacs-devel for discussion.  But you should not be _removing_ control willy
nilly from users.

Note: Personally, I use maximum font-lock decoration - this is not about my
personal use of Emacs.  It is about giving users control over their Emacs
experience, or rather not reducing their control further.  (It's also about not
redesigning in (only) a bug thread.)

This is a main point of this bug discussion:

da>  Changing the level can turn off (or on) lots of regexp 
da>  processing and the corresponding use of lots of faces -
da>  in this case faces that are used only by one level and
da>  not the other.
da> 
da>  Without this separation of regexp processing into two or
da>  more groups (levels), the user would need to customize
da>  lots of individual faces to get the effect of turning off
da>  their highlighting.  And that still would not have relieved
da>  him of the processing time for matching their regexps, even
da>  if the result were, in effect, not to highlight any such matches.
da> 
da>  A user might want some fontification - some regexps to be 
da>  matched and their text highlighted, but not want some other
da>  fontification.  However you want to do it (combine regexp
da>  sexps in an easy, customizable way? boolean "features"?
da>  whatever), we should give users the ability to choose (in 
da>  chunks) what gets fontified.
da> 
da>  As I said earlier, it would be ideal to give users an easy 
da>  way to define their own fontification levels or features or
da>  groups or whatever.  We're not there yet.  I'm all in favor
da>  of something better than hard-coded levels.  I'm not in
da>  favor of dropping levels in favor of nothing, while 
da>  ostensibly waiting for pie in the sky.

If you want to propose a _better_ way of letting users chunk font-lock
highlighting, please do.  I'm looking forward to it.

It would be better for users to be able to _define_ (not just choose) such
chunking themselves - better than the limited control they have now over the
essentially hard-coded chunks.  But please do not take away all such chunking
and a user's ability to choose the chunking to use.  And certainly do not do so
without some emacs-devel discussion.






      reply	other threads:[~2011-07-31 16:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-28  4:06 bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' Drew Adams
2010-08-28 14:41 ` Stefan Monnier
2010-08-28 19:54   ` Drew Adams
2010-08-30 14:41     ` Stefan Monnier
2010-08-30 15:46       ` Drew Adams
2010-08-30 22:04         ` Stefan Monnier
2010-08-30 22:56           ` Drew Adams
2010-08-31 10:33             ` Stefan Monnier
2011-07-14 13:49 ` Lars Magne Ingebrigtsen
2011-07-14 16:41   ` Drew Adams
2011-07-22  3:54   ` Chong Yidong
2011-07-31 15:00     ` Lars Magne Ingebrigtsen
2011-07-31 16:31       ` 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

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

  git send-email \
    --in-reply-to=A22B18C0F274478C87FECC78AB1E0288@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=6935@debbugs.gnu.org \
    --cc=cyd@stupidchicken.com \
    --cc=larsi@gnus.org \
    /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.