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: Fri, 11 Apr 2003 21:34:03 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <67B8CED503F3D511BB9F0008C75DAD6605485580@dewdfx17> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: main.gmane.org 1050089685 4193 80.91.224.249 (11 Apr 2003 19:34:45 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 11 Apr 2003 19:34:45 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Apr 11 21:34:43 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 1944IM-00015R-00 for ; Fri, 11 Apr 2003 21:34:42 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 1944Nx-00086C-00 for ; Fri, 11 Apr 2003 21:40:29 +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 1944IA-0004fZ-00 for emacs-devel@quimby.gnus.org; Fri, 11 Apr 2003 15:34:30 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 1944Hs-0004dT-00 for emacs-devel@gnu.org; Fri, 11 Apr 2003 15:34:12 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 1944Hq-0004cQ-00 for emacs-devel@gnu.org; Fri, 11 Apr 2003 15:34:11 -0400 Original-Received: from smtpde02.sap-ag.de ([155.56.68.170]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 1944Hp-0004bW-00 for emacs-devel@gnu.org; Fri, 11 Apr 2003 15:34:10 -0400 Original-Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA18524; Fri, 11 Apr 2003 21:34:21 +0200 (MESZ) Original-To: "'Kevin Rodgers'" , emacs-devel@gnu.org X-Mailer: Internet Mail Service (5.5.2656.59) X-SAP: out 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:13165 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13165 Kevin Rodgers wrote: > Wedler, Christoph wrote: >> 2. the ability to define "abstract" properties and assign one ore more >> of them to text (parts). Each abstract property represents a list of >> (concrete) properties (with their values). > Isn't that what the `category' property provides? It looks like. I wouldn't have guessed that Emacs introduces two abstraction mechanism, which - work completely different (categories: simple symbol, face: list of face names with some merging algorithm), - work for a different set of properties I think the error started when Emacs tried to define groups of different properties: 1. there are properties called text properties like `invisible', 2. there are properties called face attributes, which you have to specify together in the text property `face' (you can specify abstractions = the face name, and concrete properties = the face attributes here), 3. there are properties called display specs, which you have to specify together in the text property `display', 4. there are properties called space properties, which you have to specify together in the display spec `space', which you have to specify together with other display specs in the text property `display'. This doesn't make anything clearer, it just leads to confusion that you have to set/get/change different properties differently. Additionally, there is no clear distrinction which group you should choose for a new property. The distinction is probably not along the lines: - how => face property - where => display property if starts with The `display' text property (or overlay property) is used to insert images into text, and also control other aspects of how text displays. Therefore, some properties are defined twice: - you can specify the text size via 2 (:height) and 3 (height) - you can specify the space width via 3 (space-width) and 4 (:width) and I could somehow understand that you want to avoid a similar situation for the `raise' property... A fix would be: A. Don't define different groups of different properties: make all properties text properties (or group all special = non-user-defined text properties together) B. Just provide one abstraction mechanism for all special properties with the ability to merge the abstract properties (like face merging). I would use faces as the abstraction mechanism because - there is a way how user can customize the face properties - there is a package (font-lock) which can set the the abstract properties automatically To categories: I'm not sure whether they help me resetting "my" properties if the is a function like `remove-yank-excluded-properties' in subr.el... - Christoph