GNU bug report logs - #25824
25.1; bugs about display specfications

Previous Next

Full log

Message #8 received at 25824 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 25824 <at> debbugs.gnu.org
Subject: Re: bug#25824: 25.1; bugs about display specfications
Date: Tue, 21 Feb 2017 19:37:54 +0200

> From: ynyaaa <at> gmail.com
> Date: Tue, 21 Feb 2017 13:17:58 +0900
> 
> I found 4 bugs about display specifications.

Thank you for your report.

I don't think these are bugs, but perhaps we should clarify the
expected behavior in the docs some more.

> (1) raise display specification may be affected by height specification.
> 
> This form displays two X's on the same height.
> 
> (insert "A"
>         (propertize "X" 'display '((raise 1) (height 1)))
>         (propertize "X" 'display '((raise 1) (height 2))))
> 
> But the form below displays second X heigher than first X.
> The order in the display property is swapped.
> 
> (insert "A"
>         (propertize "X" 'display '((height 1) (raise 1)))
>         (propertize "X" 'display '((height 2) (raise 1))))

This should be expected.  The display properties in a spec that is a
list or a vector are processed one after the other, left to right
(which is really the only way that makes sense and that will produce
deterministic results).  And the documentation about 'raise' says:

  ‘(raise FACTOR)’
       [...]
       FACTOR must be a number, which is interpreted as a multiple of the
       height of the affected text.

So when the previous element of the display spec changes the height,
FACTOR converted to pixels will also change accordingly.  (The
documentation goes on to say something that could be interpreted as
contradicting the above, but that is just plain confused/wrong, and
certainly doesn't match the implementation.)

> (2) height display specification may not be applied to STRING specification.

As expected: 'height' affects display of the text in the buffer
covered by the property, but a display string completely conceals that
text, so the result is undefined.

> This form displays a large string.
> 
> (insert (propertize "X" 'display '((height 2) "TEST")))
> 
> But the form below displays a normal size string.
> 
> (insert (propertize "X" 'display '("TEST" (height 2))))

The latter is just a side effect of implementation details.  Display
string and 'raise'/'heaight' specs don't make sense together in the
same display spec.

> (3) raise display specification is not applied to STRING specification.
> 
> This form displays strings on the base line.
> 
> (insert (propertize "X" 'display '((raise 1) "TEST1"))
>         (propertize "X" 'display '("TEST2" (raise 1))))

Likewise.

> (4) raise display specification may display needless space.
> 
> This form displays needless space over A,
> as if raise specification is not specified.
> 
> (insert "A" (propertize "X" 'display '((raise -1) (height 2))))

The space is needed to accommodate the enlarged X on the same screen
line.  Emacs display engine doesn't require that all the glyphs on a
line be of the same size, but it does require them to have the same
baseline (the display geometry is that of a canvas).

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.