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: link appearance and soft face properties Date: Sun, 19 Jun 2005 10:50:46 -0700 Message-ID: References: <871x6zrj4r.fsf@jurta.org> 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 1119203988 8576 80.91.229.2 (19 Jun 2005 17:59:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 19 Jun 2005 17:59:48 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 19 19:59:46 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dk44m-0004y2-Ly for ged-emacs-devel@m.gmane.org; Sun, 19 Jun 2005 19:59:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dk4Aq-0007cb-Hf for ged-emacs-devel@m.gmane.org; Sun, 19 Jun 2005 14:05:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dk48r-00075H-W6 for emacs-devel@gnu.org; Sun, 19 Jun 2005 14:03:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dk48k-00071u-Nz for emacs-devel@gnu.org; Sun, 19 Jun 2005 14:03:31 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dk48i-0006ss-In for emacs-devel@gnu.org; Sun, 19 Jun 2005 14:03:24 -0400 Original-Received: from [141.146.126.231] (helo=agminet04.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1Dk3yy-0000yp-TW for emacs-devel@gnu.org; Sun, 19 Jun 2005 13:53:21 -0400 Original-Received: from agminet04.oracle.com (localhost [127.0.0.1]) by agminet04.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5JHom6k020750 for ; Sun, 19 Jun 2005 12:50:48 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet04.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5JHomQu020742 for ; Sun, 19 Jun 2005 12:50:48 -0500 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j5JHolui014377 for ; Sun, 19 Jun 2005 11:50:47 -0600 Original-Received: from dradamslap (dhcp-amer-whq-csvpn-gw3-141-144-80-223.vpn.oracle.com [141.144.80.223]) by rgmsgw300.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j5JHolQ7014370 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 19 Jun 2005 11:50:47 -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: <871x6zrj4r.fsf@jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= 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:39122 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:39122 > That way, a single (possibly user) definition of the :link > attribute would automatically affect any faces that have that > property. And it would also be easy (including for users) to > selectively apply the :link property to face or mouse-face > or both. > > I think this can be done by making these faces inherit > from a face named `link'. This is an interesting idea, but then for consistency this should be applied to every mouse-over attribute with follow-link property, i.e. not only in compilation and grep buffers, but also in info, dired, gnus... Yes, that's what I meant: use a predefined (but user-customizable) `link' face everywhere, for links. Currently, we have no "soft" (= user-changeable) notion of what a "link" is. In fact, even apart from a lack of customizability, we have no notion of "link", except for that provided by the `follow-link' property (which is not even used for all links). A link is currently defined only by whatever the underlying code happens to do with a mouse-1 or mouse-2 click at that position: if the code "follows a link" upon mouse click, then we can say that a link is present. One cannot assign "linkness" (behavior and appearance) to a portion of text. The appearance of a link is governed by a face or mouse-face at that position. There is no notion of a "link" object that unites function and appearance (and allows for user modification of appearance). Providing a link face (that inherits etc.) and using it for all links (i.e. places where the code in fact "follows a link" upon click) would let users customize, in a single place, how links appear. (If we provided buffer-local faces, users would also be able to easily customize link appearance on a per-buffer basis.) Best: Provide "link" objects: text that has certain properties that include both appearance and "link-following" behavior when clicked. OK (but < Best): Provide only a "link-appearance" text property or face. We would continue to count on an underlying association of locally coded mouse-click-link-behavior with the text that has the `link' property or face.