bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6935: 24.0.50; doc for `font-lock-maximum-decoration'


From: Drew Adams
Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration'
Date: Sun, 31 Jul 2011 09:31:54 -0700

> > 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 via email to

[Prev in Thread] Current Thread [Next in Thread]