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: Mon, 30 Aug 2010 15:56:07 -0700 Message-ID: <25DFEB9F124E49EA82BB01E0A16107C0@us.oracle.com> References: <0AEEE18115BA49E58E42C1604867D444@us.oracle.com><94F453208A4B4F70B7C5F87CB2BE541C@us.oracle.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 1283209799 25203 80.91.229.12 (30 Aug 2010 23:09:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 30 Aug 2010 23:09:59 +0000 (UTC) Cc: 6935@debbugs.gnu.org To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 31 01:09:55 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OqDU4-0004bC-0g for geb-bug-gnu-emacs@m.gmane.org; Tue, 31 Aug 2010 01:09:48 +0200 Original-Received: from localhost ([127.0.0.1]:49790 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OqDU3-0005dD-BZ for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Aug 2010 19:09:47 -0400 Original-Received: from [140.186.70.92] (port=54107 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OqDTx-0005cw-1E for bug-gnu-emacs@gnu.org; Mon, 30 Aug 2010 19:09:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OqDTv-0005fz-Kv for bug-gnu-emacs@gnu.org; Mon, 30 Aug 2010 19:09:40 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55408) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OqDTv-0005ft-DC for bug-gnu-emacs@gnu.org; Mon, 30 Aug 2010 19:09:39 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OqDFm-0000fl-1H; Mon, 30 Aug 2010 18:55: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: 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: Original-Received: via spool by 6935-submit@debbugs.gnu.org id=B6935.12832088792575 (code B ref 6935); Mon, 30 Aug 2010 22:55:01 +0000 Original-Received: (at 6935) by debbugs.gnu.org; 30 Aug 2010 22:54:39 +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 1OqDFO-0000fU-0d for submit@debbugs.gnu.org; Mon, 30 Aug 2010 18:54:38 -0400 Original-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 Original-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 Original-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 Original-Received: from abhmt006.oracle.com by acsmt353.oracle.com with ESMTP id 546458841283208967; Mon, 30 Aug 2010 15:56:07 -0700 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Aug 2010 15:56:06 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: ActIj0oL+hTxrrGfRjOpxMRkic8Z2wAAuQ7g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 30 Aug 2010 18:55:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:39845 Archived-At: > >> 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.