bug#25824: 25.1; bugs about display specfications

bug#25824: 25.1; bugs about display specfications

[ynyaaa]

I found 4 bugs about display specifications.

------------------------------------------------------------
(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))))

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

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))))

------------------------------------------------------------
(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))))

------------------------------------------------------------
(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))))



In GNU Emacs 25.1.1 (i686-w64-mingw32)
 of 2016-09-18 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.0.6002
Configured using:
 'configure --host=i686-w64-mingw32 --without-dbus
 --without-compress-install CFLAGS=-static'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils
misearch multi-isearch rect help-mode easymenu cl-loaddefs pcase cl-lib
debug time-date mule-util japan-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table
w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)

Memory information:
((conses 8 97029 6894)
 (symbols 32 19796 0)
 (miscs 32 83 406)
 (strings 16 16516 4085)
 (string-bytes 1 445422)
 (vectors 8 13376)
 (vector-slots 4 521906 4206)
 (floats 8 167 397)
 (intervals 28 919 15)
 (buffers 520 20))

bug#25824: 25.1; bugs about display specfications

[Eli Zaretskii]

> From: ynyaaa@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.

bug#25824: 25.1; bugs about display specfications

[ynyaaa]

Eli Zaretskii <eliz@gnu.org> writes:
> Display
> string and 'raise'/'heaight' specs don't make sense together in the
> same display spec.

The height of the replacing text can be controlled by its face.
Is there any chance to 'raise' the replacing text?

> 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).

I don't understand the relation between the space and the baseline.

I want to display large text centered vertically.
But there is a blank area over the large text.

I expect line-pixel-height of a line with 5 times larger text
is 5 times larger than a normal line.

Practically, if the large text is 'raise'd negative,
line-pixel-height is 5 times plus 'raise'd pixels larger.
(with some computational error)

;; normal line
(line-pixel-height)
=>22

;; large text without raise specification
(progn
  (insert "normal"
          (propertize "LARGE" 'display '((height 5))))
  (beginning-of-line)
  (line-pixel-height))
=>107

;; cap height is 14 and line height is 22
;; 'raise' -2 * cap height pixels
(progn
  (insert "normal"
          (propertize "LARGE" 'display '((raise -1.2727) (height 5))))
  (beginning-of-line)
  (line-pixel-height))
=>134


By the way, if the baseline height is same,
I think consecutive underlines should be displayed as one straight line.
The form below shows three underlines with different height.

(insert (propertize "X" 'face '(:underline t))
        (propertize "X" 'face '(:underline t) 'display '((raise -1)))
        (propertize "X" 'face '(:underline t) 'display '((raise 1))))

As for overlines, they are displayed as one straight line.

(insert (propertize "X" 'face '(:overline t))
        (propertize "X" 'face '(:overline t) 'display '((raise -1)))
        (propertize "X" 'face '(:overline t) 'display '((raise 1))))

bug#25824: 25.1; bugs about display specfications

[Eli Zaretskii]

> From: ynyaaa@gmail.com
> Cc: 25824@debbugs.gnu.org
> Date: Thu, 23 Feb 2017 11:53:16 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > Display
> > string and 'raise'/'heaight' specs don't make sense together in the
> > same display spec.
> 
> The height of the replacing text can be controlled by its face.
> Is there any chance to 'raise' the replacing text?

Only if the replacement comes from a before- or after-string (in which
case the text won't be replaced, so you will have to hide it with some
invisible property).  Put the 'raise' display property on the overlay
string, and you will have what you want.

> > 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).
> 
> I don't understand the relation between the space and the baseline.

Maybe this snippet will help:

  (insert "A" (propertize "X" 'display '((raise -1) (height 2)))
          (propertize "X" 'display '((height 2))))

After evaluating this, move the cursor between the 2 "X"s and look at
the top edge of the cursor block.  Do you see that the top edge is at
the same vertical coordinate in both cases?  Do you also see that
there's enough space above the 1st (lowered) "X" to display a
non-lowered "X"?  What the display engine does is reserve space above
the baseline that is large enough for the enlarged font, and then draw
the "X" with a negative offset relative to the baseline, by enlarging
the 'descent' value of that particular glyph, which adds vertical
space _below_ the line.

> I want to display large text centered vertically.
> But there is a blank area over the large text.

Does the below do what you want?  If not, perhaps I don't understand
what you mean by "centered".

  (insert "A" (propertize "X" 'display '((raise -0.2) (height 2))))

> I expect line-pixel-height of a line with 5 times larger text
> is 5 times larger than a normal line.
> 
> Practically, if the large text is 'raise'd negative,
> line-pixel-height is 5 times plus 'raise'd pixels larger.
> (with some computational error)

See above: I hope now it's clear why what you see in practice is how
the code is supposed to work.  IOW, the overall height of the screen
line is enlarged to account for the 'raise' value _after_ enlarging
the font due to 'height', because 'raise' works in font height units.

> By the way, if the baseline height is same,
> I think consecutive underlines should be displayed as one straight line.
> The form below shows three underlines with different height.

That's a separate bug (which you already reported).  It happens when
we redraw only the larger underlined glyph(s), without the smaller
one(s) to its left.

bug#25824: 25.1; bugs about display specfications

[ynyaaa]

Eli Zaretskii <eliz@gnu.org> writes:
> Only if the replacement comes from a before- or after-string (in which
> case the text won't be replaced, so you will have to hide it with some
> invisible property).  Put the 'raise' display property on the overlay
> string, and you will have what you want.

Overlays are not editable with kill and yank,
so text properties are better.

> What the display engine does is reserve space above
> the baseline that is large enough for the enlarged font, and then draw
> the "X" with a negative offset relative to the baseline, by enlarging
> the 'descent' value of that particular glyph, which adds vertical
> space _below_ the line.

I wonder why the display engine does not take 'rase' into account
when reserving space above the baseline.

> Does the below do what you want?  If not, perhaps I don't understand
> what you mean by "centered".
>
>   (insert "A" (propertize "X" 'display '((raise -0.2) (height 2))))

It is enough for only one line.
With blank areas, emacs can display fewer lines.

For example in my environment, the form below displays 9 lines.
(insert (propertize "1\n2\n3\n4\n5\n6\n7\n8\n9\n"
        'display '(height 5)))

And the form below displays 7 lines.
(insert (propertize "1\n2\n3\n4\n5\n6\n7\n8\n9\n"
        'display '((raise -1.3) (height 5))))

bug#25824: 25.1; bugs about display specfications

[Eli Zaretskii]

> From: ynyaaa@gmail.com
> Cc: 25824@debbugs.gnu.org
> Date: Fri, 24 Feb 2017 15:01:19 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > Only if the replacement comes from a before- or after-string (in which
> > case the text won't be replaced, so you will have to hide it with some
> > invisible property).  Put the 'raise' display property on the overlay
> > string, and you will have what you want.
> 
> Overlays are not editable with kill and yank,
> so text properties are better.

Then I'm afraid you are out of luck, because Emacs doesn't support
recursive 'display' properties, i.e. a 'display' property that is a
string which has another 'display' property for (a part of) that
string.

> > What the display engine does is reserve space above
> > the baseline that is large enough for the enlarged font, and then draw
> > the "X" with a negative offset relative to the baseline, by enlarging
> > the 'descent' value of that particular glyph, which adds vertical
> > space _below_ the line.
> 
> I wonder why the display engine does not take 'rase' into account
> when reserving space above the baseline.

AFAIU, it's just a side effect of the implementation: 'raise' is
implemented as modifications of the ascent or descent, so it behaves
like these attributes of any glyph would.

> > Does the below do what you want?  If not, perhaps I don't understand
> > what you mean by "centered".
> >
> >   (insert "A" (propertize "X" 'display '((raise -0.2) (height 2))))
> 
> It is enough for only one line.
> With blank areas, emacs can display fewer lines.

Yes, there are limitations of what can be done in Emacs as far as text
layout is concerned.

bug#25824: 25.1; bugs about display specfications

[Eli Zaretskii]

> Date: Fri, 24 Feb 2017 10:23:13 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 25824@debbugs.gnu.org
> 
> > From: ynyaaa@gmail.com
> > Cc: 25824@debbugs.gnu.org
> > Date: Fri, 24 Feb 2017 15:01:19 +0900
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > > Only if the replacement comes from a before- or after-string (in which
> > > case the text won't be replaced, so you will have to hide it with some
> > > invisible property).  Put the 'raise' display property on the overlay
> > > string, and you will have what you want.
> > 
> > Overlays are not editable with kill and yank,
> > so text properties are better.
> 
> Then I'm afraid you are out of luck, because Emacs doesn't support
> recursive 'display' properties, i.e. a 'display' property that is a
> string which has another 'display' property for (a part of) that
> string.
> 
> > > What the display engine does is reserve space above
> > > the baseline that is large enough for the enlarged font, and then draw
> > > the "X" with a negative offset relative to the baseline, by enlarging
> > > the 'descent' value of that particular glyph, which adds vertical
> > > space _below_ the line.
> > 
> > I wonder why the display engine does not take 'rase' into account
> > when reserving space above the baseline.
> 
> AFAIU, it's just a side effect of the implementation: 'raise' is
> implemented as modifications of the ascent or descent, so it behaves
> like these attributes of any glyph would.
> 
> > > Does the below do what you want?  If not, perhaps I don't understand
> > > what you mean by "centered".
> > >
> > >   (insert "A" (propertize "X" 'display '((raise -0.2) (height 2))))
> > 
> > It is enough for only one line.
> > With blank areas, emacs can display fewer lines.
> 
> Yes, there are limitations of what can be done in Emacs as far as text
> layout is concerned.

I've now clarified the relations between 'raise' and 'height' in the
ELisp manual, and I'm closing this bug.

Thanks.