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: Wed, 14 May 2003 19:45:40 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <67B8CED503F3D511BB9F0008C75DAD6605485601@dewdfx17> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: main.gmane.org 1052935007 22652 80.91.224.249 (14 May 2003 17:56:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 14 May 2003 17:56:47 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 14 19:56:45 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 19G0Tm-0005p1-00 for ; Wed, 14 May 2003 19:55:50 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19G0bG-0004N5-00 for ; Wed, 14 May 2003 20:03:34 +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 19G0MS-00019U-0B for emacs-devel@quimby.gnus.org; Wed, 14 May 2003 13:48:16 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19G0MB-00014b-00 for emacs-devel@gnu.org; Wed, 14 May 2003 13:47:59 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19G0M7-0000xx-00 for emacs-devel@gnu.org; Wed, 14 May 2003 13:47:57 -0400 Original-Received: from smtpde02.sap-ag.de ([155.56.68.170]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19G0KB-0000AF-00; Wed, 14 May 2003 13:45:55 -0400 Original-Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id TAA19335; Wed, 14 May 2003 19:46:06 +0200 (MESZ) Original-To: "'Miles Bader'" X-Mailer: Internet Mail Service (5.5.2656.59) X-SAP: out X-SAP: out X-SAP: out X-SAP: out Original-cc: "'rms@gnu.org'" 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:13869 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13869 Miles Bader wrote: > Your code is not a replacement for category -- category does much more. What does it more? > So why do you keep saying it's necessary only for `backward-compatibility'? Maybe an answer to your previous mail helps. > I'm not sure why it was suggested to be marked `obsolete' anyway -- > `category' is a general abstraction mechanism for text properties > (and overlays), not an ad-hoc display-related property. [...] Hmm, half my proposal was about using just one abstraction mechanism for all properties: faces. (The other half was about not trying to group properties into direct text/overlay props, display specs, face attributes, etc...) >> 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... > Do you have any evidence or reasoning to support this conclusion? It > sounds like your change would end up checking for many more > properties... Yes. The "if the above answer is b" means that Emacs merges each display spec individually, i.e., the same as the corresponding direct properties would be merged with my approach. In other words, the number of direct text/overlay props, display specs, face attributes, etc which Emacs would have to check now are not less than the number of direct properties to check with my approach. In order not to discuss hypothetical things, I checked the merging of display properties: the answer is a. Of course, that's faster, but this kind of merging is a bit limited. In other words, the more efficient implementation depends on the current semantics, which is a bit confusing. (defun dp () (interactive) (insert "MMM M1M M2M M3M M4M MMM") (let ((ol (make-overlay (- (point) 11) (- (point) 4)))) (overlay-put ol 'display '(raise 1.5)) (put-text-property (- (point) 15) (- (point) 8) 'display '(height (+ 2))) (put-text-property (- (point) 19) (- (point) 16) 'display '((raise 1.5) (height (+ 2)))))) With Emacs, only M1M is higher and raised, M3M is only raised. In my approach, where `height' and `raise' are direct properties, M3M would also be higher and raised (with my approach, the code would look different, of course: no property `display' stuff). - Christoph