From unknown Sun Jun 22 11:39:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' 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: Sat, 28 Aug 2010 04:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 6935 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 6935@debbugs.gnu.org X-Debbugs-Original-To: Received: via spool by submit@debbugs.gnu.org id=B.128296836718662 (code B ref -1); Sat, 28 Aug 2010 04:07:01 +0000 Received: (at submit) by debbugs.gnu.org; 28 Aug 2010 04:06:07 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OpCgA-0004qw-JN for submit@debbugs.gnu.org; Sat, 28 Aug 2010 00:06:06 -0400 Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OpCg9-0004qa-2b for submit@debbugs.gnu.org; Sat, 28 Aug 2010 00:06:05 -0400 Received: from lists.gnu.org ([199.232.76.165]:59655) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1OpCha-0005mA-E1 for submit@debbugs.gnu.org; Sat, 28 Aug 2010 00:07:34 -0400 Received: from [140.186.70.92] (port=46529 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OpChV-0004gw-7w for bug-gnu-emacs@gnu.org; Sat, 28 Aug 2010 00:07:33 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OpChQ-0002Dj-2y for bug-gnu-emacs@gnu.org; Sat, 28 Aug 2010 00:07:29 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]:35469) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OpChP-0002Da-UQ for bug-gnu-emacs@gnu.org; Sat, 28 Aug 2010 00:07:24 -0400 Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7S47L62023078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 28 Aug 2010 04:07:22 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7RLM2lT009173 for ; Sat, 28 Aug 2010 04:07:21 GMT Received: from abhmt003.oracle.com by acsmt353.oracle.com with ESMTP id 556491581282968365; Fri, 27 Aug 2010 21:06:05 -0700 Received: from dradamslap1 (/10.159.220.83) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 27 Aug 2010 21:06:05 -0700 From: "Drew Adams" Date: Fri, 27 Aug 2010 21:06:09 -0700 Message-ID: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActGZlgvwEkID6SrRyuKii401rU50w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -6.3 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) The doc for `font-lock-maximum-fontification' is not very clear/complete. 1. For one thing, the Emacs manual deals with it only using a `setq' example: (setq font-lock-maximum-decoration '((c-mode . 1) (c++-mode . 1))) We should tell users how they can use Customize for customizing it. (No, it is not obvious how to do that.) We should not be privileging Lisp code in .emacs this way - especially fairly complex Lisp code. 2. The doc string and the Customize help for it (same thing) do not help much either. In particular, they are missing the info that if you add an entry for one or more modes, then you will likely want to also add a catch-all entry for all other modes. The latter notion is not presented explicitly, but the example given does help in this regard. One problem is that the choice of `all' as the UI label gives the impression that it might override other, mode-specific entries. For example, you might well think that order is important and that an entry of `all' overrides any other entries that follow. `all' should really be renamed something that conveys the fact that it means `all other modes', not `all modes'. 3. Also, to understand what the choice of `level' means here, users need to know about fontification levels. At least a minimum of info about that needs to be presented in the Customize (= doc string) help. In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2010-08-16 on 3249CTO Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.4) --no-opt --cflags -Ic:/imagesupport/include' From unknown Sun Jun 22 11:39:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Aug 2010 19:02:01 +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: To: "Drew Adams" Cc: 6935@debbugs.gnu.org Received: via spool by 6935-submit@debbugs.gnu.org id=B6935.128302211913734 (code B ref 6935); Sat, 28 Aug 2010 19:02:01 +0000 Received: (at 6935) by debbugs.gnu.org; 28 Aug 2010 19:01:59 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OpQf8-0003ZT-5m for submit@debbugs.gnu.org; Sat, 28 Aug 2010 15:01:59 -0400 Received: from drizzle.cc.mcgill.ca ([132.206.27.48]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OpQf5-0003ZO-K7 for 6935@debbugs.gnu.org; Sat, 28 Aug 2010 15:01:56 -0400 Received: from mailscan2.ncs.mcgill.ca (mailscan2.NCS.McGill.CA [132.216.77.249]) by drizzle.cc.mcgill.ca (8.12.11.20060308/8.12.3) with ESMTP id o7SJ3Qph019466; Sat, 28 Aug 2010 15:03:26 -0400 Received: from mailscan2.ncs.mcgill.ca (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9B99B937E; Sat, 28 Aug 2010 15:03:26 -0400 (EDT) Received: from fmsmemgm.homelinux.net (vpn87207.VPN.McGill.CA [132.216.87.207]) by mailscan2.ncs.mcgill.ca (Postfix) with ESMTP id 32E97937C; Sat, 28 Aug 2010 15:03:26 -0400 (EDT) Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 0A36AAE3C8; Sat, 28 Aug 2010 20:50:45 +0200 (CEST) From: Stefan Monnier In-Reply-To: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> (Drew Adams's message of "Fri, 27 Aug 2010 21:06:09 -0700") Date: Sat, 28 Aug 2010 16:41:18 +0200 Message-ID: References: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2010.6.9.160619 X-McGill-WhereFrom: Internal X-Spam-Score: -5.5 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.6 (-----) > The doc for `font-lock-maximum-fontification' is not very > clear/complete. FWIW, I think this customization option (and the whole notion of level) should disappear, Stefan From unknown Sun Jun 22 11:39:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' 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: Sat, 28 Aug 2010 19:55:01 +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: To: "'Stefan Monnier'" Cc: 6935@debbugs.gnu.org Received: via spool by 6935-submit@debbugs.gnu.org id=B6935.128302529814946 (code B ref 6935); Sat, 28 Aug 2010 19:55:01 +0000 Received: (at 6935) by debbugs.gnu.org; 28 Aug 2010 19:54:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OpRUP-0003t1-KP for submit@debbugs.gnu.org; Sat, 28 Aug 2010 15:54:57 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OpRUN-0003st-CR for 6935@debbugs.gnu.org; Sat, 28 Aug 2010 15:54:55 -0400 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7SJuOg5031363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 Aug 2010 19:56:26 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7SHUR8r005514; Sat, 28 Aug 2010 19:56:24 GMT Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 557304401283025295; Sat, 28 Aug 2010 12:54:55 -0700 Received: from dradamslap1 (/10.159.221.84) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 28 Aug 2010 12:54:55 -0700 From: "Drew Adams" References: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> Date: Sat, 28 Aug 2010 12:54:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: ActG47d6RE+gAviyTO6zXHaex3tzHAABTTqg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Spam-Score: -5.6 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > > The doc for `font-lock-maximum-fontification' is not very > > clear/complete. > > FWIW, I think this customization option (and the whole notion > of level) should disappear, Why? And why just say _you think so_, with no supporting argument? I might think that all alligators should be painted yellow with blue polka-dots, but why should anyone care if I give no reason? This customization option lets users easily pick the level they want. Just yesterday I had a user report about this wrt Dired+ (my code had a bug that was preventing such a choice). Users have different needs and preferences, and they do care about them. Some means to control fontification level should be offered to users, and an option is a good way to do that. Doing away with "the whole notion of level" would mean giving users no choice. One size does _not_ fit all. It's about the users. In any case, this bug report is about specific, doc problems wrt this feature. Let's please address those. The feature works, and it always has. The doc is not perfect; that's all. From unknown Sun Jun 22 11:39:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Aug 2010 14:41: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: To: "Drew Adams" Cc: 6935@debbugs.gnu.org Received: via spool by 6935-submit@debbugs.gnu.org id=B6935.128317922317235 (code B ref 6935); Mon, 30 Aug 2010 14:41:02 +0000 Received: (at 6935) by debbugs.gnu.org; 30 Aug 2010 14:40:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oq5X4-0004Tw-GP for submit@debbugs.gnu.org; Mon, 30 Aug 2010 10:40:22 -0400 Received: from impaqm3.telefonica.net ([213.4.138.3]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oq5X1-0004Tr-RZ for 6935@debbugs.gnu.org; Mon, 30 Aug 2010 10:40:21 -0400 Received: from IMPmailhost2.adm.correo ([10.20.102.39]) by IMPaqm3.telefonica.net with bizsmtp id 0YSv1f00V0r0BT63PehYkj; Mon, 30 Aug 2010 16:41:32 +0200 Received: from ceviche.home ([217.126.152.201]) by IMPmailhost2.adm.correo with BIZ IMP id 0ehX1f00D4LyPzM1iehYfN; Mon, 30 Aug 2010 16:41:32 +0200 X-Brightmail-Tracker: AAAAAA== X-TE-authinfo: authemail="monnier$movistar.es" |auth_email="monnier@movistar.es" X-TE-AcuTerraCos: auth_cuTerraCos="cosuitnetc01" Received: by ceviche.home (Postfix, from userid 20848) id DDDA1660DF; Mon, 30 Aug 2010 16:41:31 +0200 (CEST) From: Stefan Monnier Message-ID: References: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> Date: Mon, 30 Aug 2010 16:41:31 +0200 In-Reply-To: (Drew Adams's message of "Sat, 28 Aug 2010 12:54:58 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > This customization option lets users easily pick the level they want. > Just yesterday I had a user report about this wrt Dired+ (my code had > a bug that was preventing such a choice). Users have different needs > and preferences, and they do care about them. 2 reasons: - rather than let people work around problems by reducing the level, we should work harder to make sure that the default level is OK for everyone. - "level" is the wrong way to think about this. Instead, we should have separate controls for different font-lock features. Stefan From unknown Sun Jun 22 11:39:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' 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: Mon, 30 Aug 2010 15:48:01 +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: To: "'Stefan Monnier'" Cc: 6935@debbugs.gnu.org Received: via spool by 6935-submit@debbugs.gnu.org id=B6935.128318324318817 (code B ref 6935); Mon, 30 Aug 2010 15:48:01 +0000 Received: (at 6935) by debbugs.gnu.org; 30 Aug 2010 15:47:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oq6Zu-0004tS-NZ for submit@debbugs.gnu.org; Mon, 30 Aug 2010 11:47:22 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oq6Zs-0004tN-F4 for 6935@debbugs.gnu.org; Mon, 30 Aug 2010 11:47:21 -0400 Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7UFmsr7009646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Aug 2010 15:48:55 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7UF5a8a002883; Mon, 30 Aug 2010 15:48:54 GMT Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 545121321283183219; Mon, 30 Aug 2010 08:46:59 -0700 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Aug 2010 08:46:58 -0700 From: "Drew Adams" References: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> Date: Mon, 30 Aug 2010 08:46:57 -0700 Message-ID: <94F453208A4B4F70B7C5F87CB2BE541C@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: ActIUXQ+gF8tlCotRNOhUR/iR6L3ugAB6QGQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > > This customization option lets users easily pick the level > > they want. Just yesterday I had a user report about this > > wrt Dired+ (my code had a bug that was preventing such a > > choice). Users have different needs > > and preferences, and they do care about them. > > 2 reasons: > - rather than let people work around problems by reducing the > level, It's not a question of "working around" anything. It's about providing levels to give users a choice. > we should work harder to make sure that the default level is OK > for everyone. That's silly. If there is a _default_ level then there are level choices and a notion of level. No one disagrees that the default level should provide minimal fontification. The point is to allow users to move to a higher level if they so wish. > - "level" is the wrong way to think about this. Instead, we > should have separate controls for different font-lock features. Be specific. If you are agreeing that users should have choice and control when it comes to the degree of font-locking, and you just disagree with the current "level" mechanism, then propose something specific. Note that in the case I cited the user had the ability to fine-tune fontification, for example by customizing individual faces. But he wanted a coarse-grain control, to change the _level_. That was so even though he was unaware of the current level mechanism. He sought a way to affect the level of fontification in one fell swoop. And that's just what the current level mechanism offers. If you have a better way to give users that possibility, then please propose it specifically (on emacs-devel). I'd certainly agree that the current mechanism does not give users a way to define the makeup of a given level themselves, and that that is a limitation. The makeup of each level is hard-coded. I, for one, would welcome a feature that lets users (easily) define what each level should be. That would likely mean letting them customize the font-lock keywords for each level in some way. And currently there is no good way for users to use Customize to tailor a set of font-lock keywords. From unknown Sun Jun 22 11:39:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Aug 2010 22:03: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: To: "Drew Adams" Cc: 6935@debbugs.gnu.org Received: via spool by 6935-submit@debbugs.gnu.org id=B6935.12832057621272 (code B ref 6935); Mon, 30 Aug 2010 22:03:02 +0000 Received: (at 6935) by debbugs.gnu.org; 30 Aug 2010 22:02:42 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqCR7-0000KT-BE for submit@debbugs.gnu.org; Mon, 30 Aug 2010 18:02:41 -0400 Received: from impaqm4.telefonica.net ([213.4.138.4]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqCR4-0000KL-HZ for 6935@debbugs.gnu.org; Mon, 30 Aug 2010 18:02:39 -0400 Received: from IMPmailhost6.adm.correo ([10.20.102.127]) by IMPaqm4.telefonica.net with bizsmtp id 0i3r1f00D2kvMAa3Qm4DpX; Tue, 31 Aug 2010 00:04:13 +0200 Received: from ceviche.home ([88.7.11.192]) by IMPmailhost6.adm.correo with BIZ IMP id 0m4C1f00648cRdU1mm4D4l; Tue, 31 Aug 2010 00:04:13 +0200 X-Brightmail-Tracker: AAAAAA== X-TE-authinfo: authemail="monnier$movistar.es" |auth_email="monnier@movistar.es" X-TE-AcuTerraCos: auth_cuTerraCos="cosuitnetc01" Received: by ceviche.home (Postfix, from userid 20848) id 8B619660DF; Tue, 31 Aug 2010 00:04:12 +0200 (CEST) From: Stefan Monnier Message-ID: References: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> <94F453208A4B4F70B7C5F87CB2BE541C@us.oracle.com> Date: Tue, 31 Aug 2010 00:04:12 +0200 In-Reply-To: <94F453208A4B4F70B7C5F87CB2BE541C@us.oracle.com> (Drew Adams's message of "Mon, 30 Aug 2010 08:46:57 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> we should work harder to make sure that the default level is OK >> for everyone. > That's silly. If there is a _default_ level then there are level > choices and a notion of level. Not silly at all: if the default level is OK for everyone, there's no need for the notion of "levels". > No one disagrees that the default level should provide minimal fontification. I do. And many others as well. That's why the default is and has always been to use the highest level there is. And even with this default, gnu.emacs.help was full (for several years, don't know about recent cases) of recommendations to add (setq font-lock-maximum-decoration t) to the user's .emacs. > The point is to allow users to move to a higher level if they so wish. The other way around. >> - "level" is the wrong way to think about this. Instead, we >> should have separate controls for different font-lock features. > Be specific. If you are agreeing that users should have choice and > control when it comes to the degree of font-locking, and you just > disagree with the current "level" mechanism, then propose > something specific. That's exactly what the above does: use separate controls (e.g. bool vars) for different features. > Note that in the case I cited the user had the ability to fine-tune > fontification, for example by customizing individual faces. But he > wanted a coarse-grain control, to change the _level_. I don't know that case, so can't judge why he wanted to change the level, nor why he wanted this control to be coarse. The notion of level is wrong, because there are different ways to characterize the complexity of fontification. E.g. one of them is the amount of work done to determine how to highlight the text, another is the number of distinct elements. The two aren't necessarily connected (I almost always want my highlighting to be as precise as possible, but I generally only want very few elements to be highlighted). BTW, from what you say, the notion of level was not needed for his problem since he could get the same result by tweaking faces. Now tweaking faces on a per-mode basis is not always easy, so we may need to improve this, but at least this case doesn't seem to be one that justifies the necessity of levels. Stefan From unknown Sun Jun 22 11:39:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' 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: Mon, 30 Aug 2010 22:55:01 +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: To: "'Stefan Monnier'" Cc: 6935@debbugs.gnu.org Received: via spool by 6935-submit@debbugs.gnu.org id=B6935.12832088792575 (code B ref 6935); Mon, 30 Aug 2010 22:55:01 +0000 Received: (at 6935) by debbugs.gnu.org; 30 Aug 2010 22:54:39 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqDFO-0000fU-0d for submit@debbugs.gnu.org; Mon, 30 Aug 2010 18:54:38 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqDFL-0000fP-TJ for 6935@debbugs.gnu.org; Mon, 30 Aug 2010 18:54:36 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7UMu9ac014343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Aug 2010 22:56:11 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7UDwqwQ008045; Mon, 30 Aug 2010 22:56:08 GMT Received: from abhmt006.oracle.com by acsmt353.oracle.com with ESMTP id 546458841283208967; Mon, 30 Aug 2010 15:56:07 -0700 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Aug 2010 15:56:06 -0700 From: "Drew Adams" References: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com><94F453208A4B4F70B7C5F87CB2BE541C@us.oracle.com> Date: Mon, 30 Aug 2010 15:56:07 -0700 Message-ID: <25DFEB9F124E49EA82BB01E0A16107C0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: ActIj0oL+hTxrrGfRjOpxMRkic8Z2wAAuQ7g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > >> we should work harder to make sure that the default level is OK > >> for everyone. > > > That's silly. If there is a _default_ level then there are level > > choices and a notion of level. > > Not silly at all: if the default level is OK for everyone, there's no > need for the notion of "levels". If the default level is OK to everyone as a _default_ level, that does not imply that that level is OK for everyone for their individual use. As one member of everyone, I'm OK with a very minimal level of fontification as the default for emacs-lisp-mode, but I'm not OK with using that level for myself. Being OK with having level X as the default is not the same as being OK with using level X. And no, everyone does not agree about which fontification level/degree/feature _they_ should use. One size does not fit all. > > No one disagrees that the default level should provide > > minimal fontification. > > I do. And many others as well. That's why the default is and has > always been to use the highest level there is. And even with this > default, gnu.emacs.help was full (for several years, don't know about > recent cases) of recommendations to add (setq > font-lock-maximum-decoration t) to the user's .emacs. Dunno whether you are right about what the default has been. Typically, Emacs -Q default settings have been minimal in angry-fruit-salad effects, but you might be right wrt font-lock levels. Irregardless of what the default values have been, the ability for users to set the level they want is what you have put in question. That is where the disagreement is. > > The point is to allow users to move to a higher level if > > they so wish. > > The other way around. Either way. The point is to allow users a choice of level. But apparently you are saying that the point is to allow users to move to a _lower_ level if they so wish. We can agree on that then. Users deserve to choose the level they want. If the default is high, as you say, then they should be able to choose lower, as you (apparently) claim. But you apparently disagree with yourself in that case, since you argue both for letting them move to a lower level and not letting them change level at all (no levels). > >> - "level" is the wrong way to think about this. Instead, we > >> should have separate controls for different font-lock features. > > > Be specific. If you are agreeing that users should have choice and > > control when it comes to the degree of font-locking, and you just > > disagree with the current "level" mechanism, then propose > > something specific. > > That's exactly what the above does: use separate controls (e.g. bool > vars) for different features. Be specific. Which different font-lock features for which mode? You're just hand-waving, saying that we could split fontification into a set of "features" rather than a set of levels. Sounds fine at that level of abstraction (simply replacing numeric "levels" by boolean "features"), but the proof is in the pudding. > > Note that in the case I cited the user had the ability to fine-tune > > fontification, for example by customizing individual faces. But he > > wanted a coarse-grain control, to change the _level_. > > I don't know that case, so can't judge why he wanted to change the > level, nor why he wanted this control to be coarse. > > The notion of level is wrong, because there are different ways to > characterize the complexity of fontification. E.g. one of them is the > amount of work done to determine how to highlight the text, another is > the number of distinct elements. Another is the visual effect for the user: how much is highlighted, and what is highlighted or not. > The two aren't necessarily connected > (I almost always want my highlighting to be as precise as > possible, but I generally only want very few elements to be highlighted). Sure, there are lots of such considerations. I don't oppose a superior design that gives users _more_ control over what gets highlighted, where, how much, etc. But where's the beef? Where's the specific proposal? Don't just say we should drop the user control we do offer without offering something better. If you give users more control, great. And not just more fine-grained control, but the ability to easily chunk that the way they want (into features, levels or whatever). > BTW, from what you say, the notion of level was not needed for his > problem since he could get the same result by tweaking faces. > Now tweaking faces on a per-mode basis is not always easy, so we may > need to improve this, but at least this case doesn't seem to > be one that justifies the necessity of levels. Justify the necessity? Don't be silly. Emacs itself, and its faces, fontifications, etc. are _not necessary_. Changing the level can turn off (or on) lots of regexp processing and the corresponding use of lots of faces - in this case faces that are used only by one level and not the other. Without this separation of regexp processing into two or more groups (levels), the user would need to customize lots of individual faces to get the effect of turning off their highlighting. And that still would not have relieved him of the processing time for matching their regexps, even if the result were, in effect, not to highlight any such matches. A user might want some fontification - some regexps to be matched and their text highlighted, but not want some other fontification. However you want to do it (combine regexp sexps in an easy, customizable way? boolean "features"? whatever), we should give users the ability to choose (in chunks) what gets fontified. As I said earlier, it would be ideal to give users an easy way to define their own fontification levels or features or groups or whatever. We're not there yet. I'm all in favor of something better than hard-coded levels. I'm not in favor of dropping levels in favor of nothing, while ostensibly waiting for pie in the sky. From unknown Sun Jun 22 11:39:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 31 Aug 2010 10:32: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: To: "Drew Adams" Cc: 6935@debbugs.gnu.org Received: via spool by 6935-submit@debbugs.gnu.org id=B6935.128325069121812 (code B ref 6935); Tue, 31 Aug 2010 10:32:02 +0000 Received: (at 6935) by debbugs.gnu.org; 31 Aug 2010 10:31:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqO7n-0005fl-0l for submit@debbugs.gnu.org; Tue, 31 Aug 2010 06:31:31 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqO7k-0005ff-1W for 6935@debbugs.gnu.org; Tue, 31 Aug 2010 06:31:28 -0400 Received: from ceviche.home (vpn-132-204-232-70.acd.umontreal.ca [132.204.232.70]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id o7VAX1MC003395; Tue, 31 Aug 2010 06:33:02 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 94923660DF; Tue, 31 Aug 2010 12:33:00 +0200 (CEST) From: Stefan Monnier Message-ID: References: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> <94F453208A4B4F70B7C5F87CB2BE541C@us.oracle.com> <25DFEB9F124E49EA82BB01E0A16107C0@us.oracle.com> Date: Tue, 31 Aug 2010 12:33:00 +0200 In-Reply-To: <25DFEB9F124E49EA82BB01E0A16107C0@us.oracle.com> (Drew Adams's message of "Mon, 30 Aug 2010 15:56:07 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3611=0 X-Spam-Score: -2.0 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > But you apparently disagree with yourself in that case, since you > argue both for letting them move to a lower level and not letting them > change level at all (no levels). Not I do not argue for them to be able to lower the level. That's just the functionality currently provided, and which I dislike. > Be specific. Which different font-lock features for which mode? > You're just hand-waving, saying that we could split fontification into > a set of "features" rather than a set of levels. Sounds fine at that > level of abstraction (simply replacing numeric "levels" by boolean > "features"), but the proof is in the pudding. I see no need for being more specific: whenever a particular need arises, we add a corresponding config. > Sure, there are lots of such considerations. I don't oppose > a superior design that gives users _more_ control over what gets > highlighted, where, how much, etc. I'm glad we agree. > But where's the beef? Where's the specific proposal? Don't just say > we should drop the user control we do offer without offering something > better. Strawman. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 14 09:49:57 2011 Received: (at control) by debbugs.gnu.org; 14 Jul 2011 13:49:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QhMIf-0002V5-7V for submit@debbugs.gnu.org; Thu, 14 Jul 2011 09:49:57 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QhMId-0002Us-L2 for control@debbugs.gnu.org; Thu, 14 Jul 2011 09:49:56 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=quimbies.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1QhMIS-0006iM-H1 for control@debbugs.gnu.org; Thu, 14 Jul 2011 15:49:44 +0200 Date: Thu, 14 Jul 2011 15:49:43 +0200 Message-Id: To: control@debbugs.gnu.org From: Lars Magne Ingebrigtsen Subject: control message for bug #6935 X-MailScanner-ID: 1QhMIS-0006iM-H1 X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1311256184.64375@RP1CzvH6mg1B3zOn3kUUGw X-Spam-Status: No X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) tags 6935 fixed close 6935 24.1 From unknown Sun Jun 22 11:39:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' Resent-From: Lars Magne Ingebrigtsen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jul 2011 14:03:07 +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 To: "Drew Adams" Cc: 6935@debbugs.gnu.org Received: via spool by 6935-submit@debbugs.gnu.org id=B6935.131065217115544 (code B ref 6935); Thu, 14 Jul 2011 14:03:07 +0000 Received: (at 6935) by debbugs.gnu.org; 14 Jul 2011 14:02:51 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QhMV5-00042W-AF for submit@debbugs.gnu.org; Thu, 14 Jul 2011 10:02:51 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QhMUn-000410-P1 for 6935@debbugs.gnu.org; Thu, 14 Jul 2011 10:02:33 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=quimbies.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1QhMUY-00072U-Ef; Thu, 14 Jul 2011 16:02:14 +0200 From: Lars Magne Ingebrigtsen In-Reply-To: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> (Drew Adams's message of "Fri, 27 Aug 2010 21:06:09 -0700") Date: Thu, 14 Jul 2011 15:49:41 +0200 Message-ID: References: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) X-Now-Playing: Depeche Mode's _Some Great Reward_: "Lie To Me" X-Hashcash: 1:23:110714:6935@debbugs.gnu.org::6Sd1NkfLuqL4zXD6:000000000000000000000000000000000000000001SMn X-Hashcash: 1:23:110714:drew.adams@oracle.com::lxfwu/p/wbSbRPPM:00000000000000000000000000000000000000012PzA MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1QhMUY-00072U-Ef X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1311256934.58431@B/ZZPEQ14Zu9pvwfEd1dUw X-Spam-Status: No X-Spam-Score: -2.7 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) "Drew Adams" writes: > 1. For one thing, the Emacs manual deals with it only using a `setq' > example: > > (setq font-lock-maximum-decoration > '((c-mode . 1) (c++-mode . 1))) > > We should tell users how they can use Customize for customizing it. > (No, it is not obvious how to do that.) We should not be privileging > Lisp code in .emacs this way - especially fairly complex Lisp code. For examples of complex variables like this, I find Lisp code a lot clearer than convoluted Customize settings. So this is not a bug, in my opinion. > 2. The doc string and the Customize help for it (same thing) do not help > much either. In particular, they are missing the info that if you add > an entry for one or more modes, then you will likely want to also add > a catch-all entry for all other modes. The doc string seems to have been fixed in this regard, with a pretty clear example. > 3. Also, to understand what the choice of `level' means here, users need > to know about fontification levels. At least a minimum of info about > that needs to be presented in the Customize (= doc string) help. I've now mentioned that higher levels mean more fontification. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From unknown Sun Jun 22 11:39:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' 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: Thu, 14 Jul 2011 16:42:03 +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 To: "'Lars Magne Ingebrigtsen'" Cc: 6935@debbugs.gnu.org Received: via spool by 6935-submit@debbugs.gnu.org id=B6935.131066170017625 (code B ref 6935); Thu, 14 Jul 2011 16:42:03 +0000 Received: (at 6935) by debbugs.gnu.org; 14 Jul 2011 16:41:40 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QhOyp-0004aE-KP for submit@debbugs.gnu.org; Thu, 14 Jul 2011 12:41:39 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QhOyn-0004Zy-Bb for 6935@debbugs.gnu.org; Thu, 14 Jul 2011 12:41:38 -0400 Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p6EGfSbm006451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2011 16:41:30 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p6EGfRvG005088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2011 16:41:27 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p6EGfLHW027383; Thu, 14 Jul 2011 11:41:21 -0500 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Jul 2011 09:41:21 -0700 From: "Drew Adams" References: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> Date: Thu, 14 Jul 2011 09:41:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcxCLq1H0XsjlBkASzCX3IMJpDo9CAAFKKsA 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.0A020204.4E1F1C3A.01A5:SCFSTAT5015188, ss=1, re=-4.000, fgs=0 X-Spam-Score: -4.3 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.3 (----) > > the Emacs manual deals with it only using a `setq' example: > > (setq font-lock-maximum-decoration > > '((c-mode . 1) (c++-mode . 1))) > > > > We should tell users how they can use Customize for customizing it. > > (No, it is not obvious how to do that.) We should not be > > privileging Lisp code in .emacs this way - especially fairly > > complex Lisp code. > > For examples of complex variables like this, I find Lisp code a lot > clearer than convoluted Customize settings. So this is not a > bug, in my opinion. It's not about your personal opinion of Customize. It's about Emacs's policy of privileging Customize in user doc. AFAIK, Emacs Dev _wants_ users to go first to Customize, in general - especially new users. Among other things, Customize provides various safety and sanity checks. If you have specific improvements in mind for Customize, feel free to submit them as enhancement requests. That's unrelated to this bug report. But the policy has been, in general, to move old suggestions about using `setq' etc. in .emacs to suggestions about using Customize. -- FWIW, I too used to resist Customize and do everything using hand-written Lisp in .emacs. And I too still think the Customize UI could use a lot of improvement (to put it politely). But I finally switched a few years back to using Customize and a separate `custom-file' for most, and especially for run-of-the-mill, customizations. I use Lisp code for things that Customize cannot do, not just to set an option's value. From unknown Sun Jun 22 11:39:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' Resent-From: Chong Yidong Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Jul 2011 03:55: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 To: Lars Magne Ingebrigtsen Cc: 6935@debbugs.gnu.org, Drew Adams Received: via spool by 6935-submit@debbugs.gnu.org id=B6935.131130688711093 (code B ref 6935); Fri, 22 Jul 2011 03:55:02 +0000 Received: (at 6935) by debbugs.gnu.org; 22 Jul 2011 03:54:47 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qk6p4-0002ss-6E for submit@debbugs.gnu.org; Thu, 21 Jul 2011 23:54:46 -0400 Received: from vm-emlprdomr-04.its.yale.edu ([130.132.50.145]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qk6p1-0002sg-U7 for 6935@debbugs.gnu.org; Thu, 21 Jul 2011 23:54:44 -0400 Received: from furball (c-76-28-93-216.hsd1.ct.comcast.net [76.28.93.216]) (authenticated bits=0) by vm-emlprdomr-04.its.yale.edu (8.14.4/8.14.4) with ESMTP id p6M3sYic010211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Jul 2011 23:54:35 -0400 From: Chong Yidong References: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> Date: Thu, 21 Jul 2011 23:54:34 -0400 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Thu, 14 Jul 2011 15:49:41 +0200") Message-ID: <87r55j2cn9.fsf@stupidchicken.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.71 on 130.132.50.145 X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) 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. From unknown Sun Jun 22 11:39:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' Resent-From: Lars Magne Ingebrigtsen 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 15:02: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 To: Chong Yidong Cc: 6935@debbugs.gnu.org, Drew Adams Received: via spool by 6935-submit@debbugs.gnu.org id=B6935.13121245054678 (code B ref 6935); Sun, 31 Jul 2011 15:02:02 +0000 Received: (at 6935) by debbugs.gnu.org; 31 Jul 2011 15:01:45 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QnXWR-0001DN-LD for submit@debbugs.gnu.org; Sun, 31 Jul 2011 11:01:44 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QnXWO-0001DF-6k for 6935@debbugs.gnu.org; Sun, 31 Jul 2011 11:01:41 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1QnXW0-0005JG-E0; Sun, 31 Jul 2011 17:01:16 +0200 From: Lars Magne Ingebrigtsen In-Reply-To: <87r55j2cn9.fsf@stupidchicken.com> (Chong Yidong's message of "Thu, 21 Jul 2011 23:54:34 -0400") Date: Sun, 31 Jul 2011 17:00:37 +0200 Message-ID: References: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> <87r55j2cn9.fsf@stupidchicken.com> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEUwLzgKDB8tLDcxMToC BRlFR1QXGi0CcmraAAACPElEQVQ4jWWUTW7jMAyFBQk9gDqK1q489VqJ4OyN8Xg/8dB7OS3vf4R5 pJ0/jIAGqL6QfHykYooe5uq9DyM+ol70Zgf9srLXs4EC4Fw2vC7Xox+HF1BKNkgUw4gzvKYyUmPU 46c9Qo/1vvowKLmBJptkkogKQZNNDqldMRkBKXGnau/AaHFj00p1vx8nXOVGgEbci49T44o1zpgs yaRvkSQg4f8sqjawJ5IaOW9yc0rpGRhoEtBYBf5RowgxqREVz8CUfPMK7lb/JNfdwWsEjgCxKm3u atDUGNuoKuhOMqEgxoe7iZgTOq011m0eDyCW2eq/L2Ecnm0XYCVVF8bIrO7uqaQQii/jEHkOD6Cf AF8ARPUO3DZztDGMP4iOj9FKM4m1hQPRxzg0LqcWqXLGUBhi69QLkM6zK7sxzGGgX/RfjYz9fKdK WmMHb9i6coJZ70QHjUjubRZA1NMlfQTcLkR/w+QQSPPWx6kcRRL9wRbdlhqzxV9/Hn7LF2Xbze6G 3FtaDp8CVo5xLy57WjIASswx4W3tqbJ+gQg+Lbyupay3Go0khM7DwpzanroWg8PuYKmwWESXrrQt Iilh4Da1stGYvlaWU+a1BXCy6iJr3a7R8Yll08VxicCrbRXgQaDBE9JtAG+QUaCUlmuUEo3TR4AI 5sgt5sOwJFt5Hyo5dfH6U5aEeU0iRy71EV7T+tkFkO+zilFLTLbpcOKSPH5j4rndgfZv46n2l/gF c/lm+7z9dHT1OsvvT417S/8Asi3WM1M58uMAAAAASUVORK5CYII= X-Now-Playing: Clan of Xymox's _Medusa_: "Michelle" MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1QnXW0-0005JG-E0 X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1312729276.69962@4aGC7WoX5Uh5QKTssyXrKg X-Spam-Status: No X-Spam-Score: -2.7 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) Chong Yidong writes: > 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". -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 31 11:01:39 2011 Received: (at control) by debbugs.gnu.org; 31 Jul 2011 15:01:39 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QnXWM-0001D8-Tr for submit@debbugs.gnu.org; Sun, 31 Jul 2011 11:01:39 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QnXWK-0001Cz-3T for control@debbugs.gnu.org; Sun, 31 Jul 2011 11:01:37 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1QnXVw-0005J6-BP for control@debbugs.gnu.org; Sun, 31 Jul 2011 17:01:12 +0200 Date: Sun, 31 Jul 2011 17:00:53 +0200 Message-Id: To: control@debbugs.gnu.org From: Lars Magne Ingebrigtsen Subject: control message for bug #6935 X-MailScanner-ID: 1QnXVw-0005J6-BP X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1312729272.60306@VT+x2JMQgu7rotfVWwEQRw X-Spam-Status: No X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) tags 6935 pending From unknown Sun Jun 22 11:39:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#6935: 24.0.50; doc for `font-lock-maximum-decoration' 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 To: "'Lars Magne Ingebrigtsen'" , "'Chong Yidong'" Cc: 6935@debbugs.gnu.org Received: via spool by 6935-submit@debbugs.gnu.org id=B6935.131212995225396 (code B ref 6935); Sun, 31 Jul 2011 16:33:02 +0000 Received: (at 6935) by debbugs.gnu.org; 31 Jul 2011 16:32:32 +0000 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 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 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 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 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 Received: from dradamslap1 (/10.159.51.94) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 31 Jul 2011 09:32:01 -0700 From: "Drew Adams" References: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com> <87r55j2cn9.fsf@stupidchicken.com> Date: Sun, 31 Jul 2011 09:31:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-Spam-Score: -4.2 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) > > 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.