From mboxrd@z Thu Jan  1 00:00:00 1970
Path: main.gmane.org!not-for-mail
From: "Wedler, Christoph" <christoph.wedler@sap.com>
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: <emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org>
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 <emacs-devel@main.gmane.org>; 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 <emacs-devel@quimby.gnus.org>; 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'" <miles@gnu.org>
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'" <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. <emacs-devel.gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Post: <mailto:emacs-devel@gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
List-Archive: <http://mail.gnu.org/pipermail/emacs-devel>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=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