From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' Date: Sun, 31 Jul 2011 09:31:54 -0700 Message-ID: References: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> <87r55j2cn9.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1312129980 9262 80.91.229.12 (31 Jul 2011 16:33:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 31 Jul 2011 16:33:00 +0000 (UTC) Cc: 6935@debbugs.gnu.org To: "'Lars Magne Ingebrigtsen'" , "'Chong Yidong'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 31 18:32:51 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QnYwd-0006Sp-6U for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 Jul 2011 18:32:51 +0200 Original-Received: from localhost ([::1]:55301 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnYwc-0003DG-Mr for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 Jul 2011 12:32:50 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnYwY-0003Cn-NO for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2011 12:32:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QnYwX-0002Fo-Fo for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2011 12:32:46 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41191) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnYwX-0002Fk-E4 for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2011 12:32:45 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QnYwo-0006cJ-EQ; Sun, 31 Jul 2011 12:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Jul 2011 16:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6935 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed pending Original-Received: via spool by 6935-submit@debbugs.gnu.org id=B6935.131212995225396 (code B ref 6935); Sun, 31 Jul 2011 16:33:02 +0000 Original-Received: (at 6935) by debbugs.gnu.org; 31 Jul 2011 16:32:32 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QnYwK-0006bY-NA for submit@debbugs.gnu.org; Sun, 31 Jul 2011 12:32:32 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QnYwI-0006bQ-5t for 6935@debbugs.gnu.org; Sun, 31 Jul 2011 12:32:31 -0400 Original-Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p6VGW9cN015801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 31 Jul 2011 16:32:11 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p6VGW7xe001124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Jul 2011 16:32:08 GMT Original-Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p6VGW110015773; Sun, 31 Jul 2011 11:32:01 -0500 Original-Received: from dradamslap1 (/10.159.51.94) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 31 Jul 2011 09:32:01 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcxPkrznPg9qRhaLQISW7e0q9P1ZWgACS2dw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090202.4E35838B.0056,ss=1,re=0.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 31 Jul 2011 12:33:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:49748 Archived-At: > > 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.