From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: definition lines in Info - 1) link, 2) highlight Date: Tue, 15 Aug 2006 16:24:48 -0700 Message-ID: References: <87bqqllimu.fsf@stupidchicken.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1155684314 19672 80.91.229.2 (15 Aug 2006 23:25:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 15 Aug 2006 23:25:14 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 16 01:25:13 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GD8HX-0000nq-Ow for ged-emacs-devel@m.gmane.org; Wed, 16 Aug 2006 01:25:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GD8HX-0002Dy-3D for ged-emacs-devel@m.gmane.org; Tue, 15 Aug 2006 19:25:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GD8HM-0002Dt-Rk for emacs-devel@gnu.org; Tue, 15 Aug 2006 19:25:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GD8HK-0002DX-1b for emacs-devel@gnu.org; Tue, 15 Aug 2006 19:25:00 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GD8HJ-0002DT-Sx for emacs-devel@gnu.org; Tue, 15 Aug 2006 19:24:57 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1GD8NS-0005Wn-6I for emacs-devel@gnu.org; Tue, 15 Aug 2006 19:31:18 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k7FNOtow032341 for ; Tue, 15 Aug 2006 18:24:55 -0500 Original-Received: from dradamslap (dhcp-amer-whq-csvpn-gw3-141-144-81-31.vpn.oracle.com [141.144.81.31]) by rgmgw2.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k7FNOsKE024553 for ; Tue, 15 Aug 2006 17:24:55 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <87bqqllimu.fsf@stupidchicken.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:58424 Archived-At: > > It doesn't need to use new faces. Surely there is > > some existing font lock face that would be usable. > > > > Faces are like global variables - user options. You > > wouldn't think of "reusing" some user option that > > happened to have a default value of t or nil or 100 > > that you were after, instead of defining a new > > user option that had the same default value - because > > customizing one might not be appropriate for the uses > > of the other. The same is true of faces. > > [Rest of lecture deleted] > > Uhm, Drew? There is a slight probability that Richard > has some passing acquaintance with faces. Instead of > lecturing him, it might be smarter to ask for an > explanation if you don't get his point. > > Sorry to blaspheme in your eyes, but... Richard is > (shudder) human, and is not always right. Please don't > assume that disagreeing with Richard means not > understanding his point. Likewise, Jesus, Mohammed, > Buddha, Marx, Dylan, and the rest. > > As to *your* technical point in this discussion: =? Though David was a tad abrasive in pointing this out, I too didn't see the point of your grand-post. Then I wasn't clear. The points were these: 1) Don't reuse faces for this feature, especially if only because someone might be in a hurry - wait until after the release, and then do it right. 2) The more important suggestion for this feature is to link to the source code and display the current value (for a variable) - and that would need to wait until after the release anyway. In sum, the point is that implementing this feature after the release makes sense. After all, the whole point of the default font-lock faces is to be re-used in many different situations. Ah, *font-lock* faces. Yes, indeed. They are to be reused in many different *font-lock* situations. IMO, it is usually *not* appropriate to reuse a font-lock face for something that is not font-lock-related. Do you disagree? If I give you a face for the mode-line (or for the gimwort), for instance, and instead of creating a new face I reuse `font-lock-comment-face', is that a good idea? Not IMO. Of course, there would be nothing wrong with reuse by copying the default value of `font-lock-comment-face', but simply pointing to the existing face is not TRT, IMO.