RE: [Feature request] face property `raise'

["Wedler, Christoph" <christoph.wedler@sap.com>]

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