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 07:57:46 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1155653898 15388 80.91.229.2 (15 Aug 2006 14:58:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 15 Aug 2006 14:58:18 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 15 16:58:15 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 1GD0Mw-00027S-Qr for ged-emacs-devel@m.gmane.org; Tue, 15 Aug 2006 16:58:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GD0Mw-0002Em-AI for ged-emacs-devel@m.gmane.org; Tue, 15 Aug 2006 10:58:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GD0Mh-0002Cv-80 for emacs-devel@gnu.org; Tue, 15 Aug 2006 10:57:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GD0Md-0002Ae-F3 for emacs-devel@gnu.org; Tue, 15 Aug 2006 10:57:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GD0Md-0002Ab-9F for emacs-devel@gnu.org; Tue, 15 Aug 2006 10:57:55 -0400 Original-Received: from [148.87.113.118] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1GD0Sg-0007lB-FU for emacs-devel@gnu.org; Tue, 15 Aug 2006 11:04:10 -0400 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k7FEvqYO010693 for ; Tue, 15 Aug 2006 08:57:52 -0600 Original-Received: from dradamslap (dhcp-amer-whq-csvpn-gw3-141-144-81-31.vpn.oracle.com [141.144.81.31]) by rgmgw3.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k7FEvpHV012230 for ; Tue, 15 Aug 2006 08:57:51 -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: 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:58407 Archived-At: > I think it could be a lot simpler. Just add a loop to > Info-fontify-node which would search for that regexp and > apply some faces to the parts that match. Introducing new faces is never simple. 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. People can, for instance, use a different background for special-display buffers such as *Info*, and a face that is appropriate for non-special-display buffers might not then be appropriate for *Info*. Even an existing Info face might not be appropriate here, depending on how users might have customized it. How about waiting until after the release for this, and doing it right, creating separate faces for this feature? The other, related suggestion here was more important, and would wait until after the release anyway (if implemented): link to the source code and display the current value (for a variable). BTW, I'm curious - why is introducing new faces not simple? Is it because of trying to get the default value right for different types of display and different background values? Perhaps there are some guidelines that might apply here? I don't know; I'm just curious what the difficulty is. As I say, better to do it right, after the release, than to do a hurried job poorly now. But, if you do want to do it now, it might be better to define new faces that might not have great default values for all contexts than it would be to reuse existing faces. If you define new faces, even bad ones, users can at least customize them independently. And users will provide feedback to help you tweak the default values so they work well in all contexts.