From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Wedler, Christoph" Newsgroups: gmane.emacs.devel Subject: RE: [Feature request] face property `raise' Date: Tue, 13 May 2003 19:17:53 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <67B8CED503F3D511BB9F0008C75DAD66054855FF@dewdfx17> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: main.gmane.org 1052847278 10280 80.91.224.249 (13 May 2003 17:34:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 13 May 2003 17:34:38 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 13 19:34:35 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 19FdZT-0002FZ-00 for ; Tue, 13 May 2003 19:28:11 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19FdgS-0006Y7-00 for ; Tue, 13 May 2003 19:35:24 +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 19FdZo-0001Ln-0C for emacs-devel@quimby.gnus.org; Tue, 13 May 2003 13:28:32 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19FdTk-0007FO-00 for emacs-devel@gnu.org; Tue, 13 May 2003 13:22:16 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19FdQn-00068S-00 for emacs-devel@gnu.org; Tue, 13 May 2003 13:19:22 -0400 Original-Received: from smtpde02.sap-ag.de ([155.56.68.170]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19FdPi-0005J1-00; Tue, 13 May 2003 13:18:06 -0400 Original-Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id TAA20437; Tue, 13 May 2003 19:18:20 +0200 (MESZ) Original-To: "'rms@gnu.org'" X-Mailer: Internet Mail Service (5.5.2656.59) X-SAP: out X-SAP: out 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:13836 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13836 Richard Stallman wrote: > 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. That's true then for face properties. If this is generally true, this would mean: - overlay A from S to E with high prio, mouse-face: nil - overlay B from S to E with low prio, mouse-face: some-face => there is no highlighting when the mouse is in the region S to E Is this the case? Or is there highlighting (nil would be the null value for mouse-face). > 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): > [...] b. prop-name, i.e., another symbol > I would suggest to use b: I agree. > 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. Stefan is probably right that this is might not be true anymore... > b. direct face attributes in the face property: > iii. obsolete, use it (with prio as it is now) > That would be necessary. Sure, if backward-compatibility is an important issue... > c. category attribute > ii. obsolete, use the symbol as an additional face (with lowest > prio) > That would be necessary. Same as above (backward-compatibility). > Meanwhile, there is an important implementation efficiency issue here. > The display code currently checks for just a few properties, and that > makes it efficient. It depends -- let's look at an example with overlays both defining the display property: - overlay A from S to E with high prio, display: (D1 a1 D2 a2) - overlay B from S to E with low prio, display: (D1 b1 D3 b3) What's the "combined" display property? a. (D1 a1 D2 a2) ? b. (D1 a1 D2 a2 D3 b3) I assume the answer is a. But, if we see the properties Dx as independent properties, b would be the correct answer. (A similar example could be constructed with face attributes in the property `face' -- what's the answer there?) > Clean though this new design is, we may need to stay with the old > design if we cannot make the new one efficient. Without extra checks for backward-compatibility properties ('category' etc) and if the above answer is b, there don't need to be a difference with the efficiency. Otherwise, there might be... - Christoph