From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: [Feature request] face property `raise' Date: Mon, 12 May 2003 21:47:55 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <67B8CED503F3D511BB9F0008C75DAD66054855B9@dewdfx17> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1052790873 2266 80.91.224.249 (13 May 2003 01:54:33 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 13 May 2003 01:54:33 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 13 03:54:32 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19FOzw-0000aC-00 for ; Tue, 13 May 2003 03:54:32 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19FP6b-0005sB-00 for ; Tue, 13 May 2003 04:01:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19FOzV-0007jA-04 for emacs-devel@quimby.gnus.org; Mon, 12 May 2003 21:54:05 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19FOuU-0006EV-00 for emacs-devel@gnu.org; Mon, 12 May 2003 21:48:54 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19FOuC-0005nj-00 for emacs-devel@gnu.org; Mon, 12 May 2003 21:48:38 -0400 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19FOtX-0004wg-00 for emacs-devel@gnu.org; Mon, 12 May 2003 21:47:55 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.10) id 19FOtX-0005Lu-00; Mon, 12 May 2003 21:47:55 -0400 Original-To: "Wedler, Christoph" In-reply-to: <67B8CED503F3D511BB9F0008C75DAD66054855B9@dewdfx17> (christoph.wedler@sap.com) Original-cc: ihs_4664@yahoo.com X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:13817 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13817 Please forgive me for taking a long time to look at this proposal. It is not that I am not interested. As opposed to the current behaviour (new in Emacs-21?), you cannot specify individual properties with the text property `face', because this is not needed: face attributes are normal "direct" text/overlay properties. That would be an incompatible change. For the sake of not breaking applications, let's not change this one thing. Questions considered below: - face/property merging: a property is defined directly and/or in more than one face -- which one to choose? This issue exists in the current design, and we resolved it by saying that faces are specified in some order. The specification of any given property wins. - how does the face/property merging relate with properties specified by overlays? Overlays come before text properties, same as now. The ordering among properties is controlled by the priority. iii. :null (or some other value) = not specified. In this case `get-text-property' and friends must return that value if a properties is not specified In the current design, the value :unspecified means aface attribute is unspecified. I think that is essentially your option 3. I think we should use alists, so that the absence of a property in an alist is clearly distinct from specifying nil. I see two possibilities for a naming convention for built-in properties (I do not discuss the individual names of the properties in this mail): a. :prop-name, i.e. a symbol starting with a colon, b. prop-name, i.e., another symbol Currently, text/overlay properties use a, face attribute use b, display properties use a and space properties (grouped in the display spec `space') use b. Yes, it is rather inconsistent. I would suggest to use b: I agree; the backward-compatibility issue is decisive. However, we could recognize the existing face attribute keywords as properties too. a. The display property. The options: i. obsolete, ignore it I think that is ok. The display property is not used in very much code. b. direct face attributes in the face property: iii. obsolete, use it (with prio as it is now) That would be necessary. c. category attribute ii. obsolete, use the symbol as an additional face (with lowest prio) That would be necessary. Meanwhile, there is an important implementation efficiency issue here. The display code currently checks for just a few properties, and that makes it efficient. Clean though this new design is, we may need to stay with the old design if we cannot make the new one efficient.