bug#43506: 26.1; line-height sometimes has no effect on the line height

bug#43506: 26.1; line-height sometimes has no effect on the line height

[Markus Triska]

To reproduce this issue, please start Emacs with "emacs -Q" and then
evaluate the following form:

    (progn
      (goto-char (point-max))
      (insert "\n")
      (insert (propertize "\n" 'line-height 3))
      (forward-line -1)
      (line-pixel-height))

In my case, the minibuffer then states "17". The expected result is 3,
because documentation states:

       A newline can have a ‘line-height’ text or overlay property that
    controls the total height of the display line ending in that newline.

For comparison, it works exactly as expected if I change "3" to "300" in
the snippet above, yielding "300" in the minibuffer.

If possible, could you please make line-height control the total height
of the display line also in the original example, or alternatively
consider changing the documentation to mention all relevant exceptions?

Thank you and all the best!
Markus

In GNU Emacs 26.1 (build 1, x86_64-apple-darwin15.3.0, X toolkit, Xaw scroll bars)
 of 2018-09-22 built on mt-laptop
Windowing system distributor 'The X.Org Foundation', version 11.0.11502000

bug#43506: 26.1; line-height sometimes has no effect on the line height

[Eli Zaretskii]

tags 43506 notabug
thanks

> From: Markus Triska <triska@metalevel.at>
> Date: Sat, 19 Sep 2020 09:21:38 +0200
> 
>     (progn
>       (goto-char (point-max))
>       (insert "\n")
>       (insert (propertize "\n" 'line-height 3))
>       (forward-line -1)
>       (line-pixel-height))
> 
> In my case, the minibuffer then states "17". The expected result is 3,
> because documentation states:
> 
>        A newline can have a ‘line-height’ text or overlay property that
>     controls the total height of the display line ending in that newline.

That's not all the documentation says about 'line-height'.  It also
says this (in the "Line Height" node referenced from the place you
cite):

     There are several ways to explicitly specify a larger line height,
  either by specifying an absolute height for the display line, or by
  specifying vertical space.  However, no matter what you specify, the
  actual line height can never be less than the default.
  [...]
     Finally, a newline can have a ‘line-spacing’ text or overlay property
  that can enlarge the default frame line spacing and the buffer local
  ‘line-spacing’ variable: if its value is larger than the buffer or frame
  defaults, that larger value is used instead, for the display line ending
  in that newline.

IOW, this property can only enlarge the line's height, which is
confirmed by the fact that using 300 in your example does work as
expected.

This is not a bug.  This property exists so a Lisp program could
produce higher lines than the default.

To produce lower lines, you can use a face with a low :height
attribute, and arrange for the newline to have that face.  You can
find an example of doing that in log-edit.el.

> If possible, could you please make line-height control the total height
> of the display line also in the original example, or alternatively
> consider changing the documentation to mention all relevant exceptions?

The documentation already mentions the limitations, see above.

bug#43506: 26.1; line-height sometimes has no effect on the line height

[Markus Triska]

Eli Zaretskii <eliz@gnu.org> writes:

>      There are several ways to explicitly specify a larger line height,
>   either by specifying an absolute height for the display line, or by
>   specifying vertical space.  However, no matter what you specify, the
>   actual line height can never be less than the default.

I find that this is not the case: For example, if I change "3" to "t" in
the snippet I posted, then I get "0" in the minibuffer, indicating that
the line height can become as low as 0 by using this property.

> IOW, this property can only enlarge the line's height, which is
> confirmed by the fact that using 300 in your example does work as
> expected.

Please see above: The property seems to be usable to get very small line
heights too. However, it does not seem to work for integers.

> The documentation already mentions the limitations, see above.

The limitations seem not to be correctly documented at the moment.

Thank you and all the best,
Markus

bug#43506: 26.1; line-height sometimes has no effect on the line height

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: 43506@debbugs.gnu.org
> Date: Sat, 19 Sep 2020 12:07:24 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >      There are several ways to explicitly specify a larger line height,
> >   either by specifying an absolute height for the display line, or by
> >   specifying vertical space.  However, no matter what you specify, the
> >   actual line height can never be less than the default.
> 
> I find that this is not the case: For example, if I change "3" to "t" in
> the snippet I posted, then I get "0" in the minibuffer, indicating that
> the line height can become as low as 0 by using this property.

The value t is not a valid value for the line-height property.  So you
are invoking "unspecified behavior" here by using it.

> > IOW, this property can only enlarge the line's height, which is
> > confirmed by the fact that using 300 in your example does work as
> > expected.
> 
> Please see above: The property seems to be usable to get very small line
> heights too.

That the invalid value t produces a zero-height screen line might be a
separate bug in the display engine, but AFAICT it's harmless: the
cursor is displayed normally, and a zero-height screen line is useless
anyway, because you cannot show anything in that line.

> However, it does not seem to work for integers.

As documented.

> > The documentation already mentions the limitations, see above.
> 
> The limitations seem not to be correctly documented at the moment.

The limitations are documented; what happens when you use invalid
values isn't (and doesn't have to be).

bug#43506: 26.1; line-height sometimes has no effect on the line height

[Eli Zaretskii]

> Date: Sat, 19 Sep 2020 14:06:08 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 43506@debbugs.gnu.org
> 
> > From: Markus Triska <triska@metalevel.at>
> > Cc: 43506@debbugs.gnu.org
> > Date: Sat, 19 Sep 2020 12:07:24 +0200
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > >      There are several ways to explicitly specify a larger line height,
> > >   either by specifying an absolute height for the display line, or by
> > >   specifying vertical space.  However, no matter what you specify, the
> > >   actual line height can never be less than the default.
> > 
> > I find that this is not the case: For example, if I change "3" to "t" in
> > the snippet I posted, then I get "0" in the minibuffer, indicating that
> > the line height can become as low as 0 by using this property.
> 
> The value t is not a valid value for the line-height property.  So you
> are invoking "unspecified behavior" here by using it.

Sorry, my bad.  The value of t _is_ valid, as documented in the ELisp
manual:

     If the property value is ‘t’, the newline character has no effect on
  the displayed height of the line—the visible contents alone determine
  the height.  The ‘line-spacing’ property, described below, is also
  ignored in this case.  This is useful for tiling small images (or image
  slices) without adding blank areas between the images.

This feature is indeed used in image.el, which see.

So the value of t indeed can cause an empty line to appear to have a
zero pixel-height, but such an empty line cannot display anything, and
the cursor on that line will have its normal default height.  The use
case for using this value is as described above, and does not make
sense for empty lines.

All other values of this property cannot make the line's height
smaller, as documented.

The conclusion is as before: an integer value of the 'line-height'
property cannot make the line's height on display smaller than the
default height.

bug#43506: 26.1; line-height sometimes has no effect on the line height

[Markus Triska]

Eli Zaretskii <eliz@gnu.org> writes:

> The value t is not a valid value for the line-height property.  So you
> are invoking "unspecified behavior" here by using it.

This is very surprising to read, because the documentation itself states:

        If the property value is ‘t’, the newline character has no effect on
    the displayed height of the line—the visible contents alone determine   
    the height.

Is it indeed true that t is not a valid value for the line-height property?

In one of my applications, I am using the t property to ensure that
adding a newline does not increase the line height in any way, and I
would prefer if this behaviour is retained also in future Emacs versions.

> The limitations are documented; what happens when you use invalid
> values isn't (and doesn't have to be).

What is documented seems to contradict what I observe, and also what the
documentation itself states in other places.

All the best,
Markus