GNU bug report logs - #43506
26.1; line-height sometimes has no effect on the line height

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43506 in the body.
You can then email your comments to 43506 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Markus Triska <triska <at> metalevel.at>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1; line-height sometimes has no effect on the line height
Date: Sat, 19 Sep 2020 09:21:38 +0200

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 43506 <at> debbugs.gnu.org
Subject: Re: bug#43506: 26.1;
 line-height sometimes has no effect on the line height
Date: Sat, 19 Sep 2020 11:45:06 +0300

tags 43506 notabug
thanks

> From: Markus Triska <triska <at> 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.

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

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43506 <at> debbugs.gnu.org
Subject: Re: bug#43506: 26.1;
 line-height sometimes has no effect on the line height
Date: Sat, 19 Sep 2020 12:07:24 +0200

Eli Zaretskii <eliz <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 43506 <at> debbugs.gnu.org
Subject: Re: bug#43506: 26.1;
 line-height sometimes has no effect on the line height
Date: Sat, 19 Sep 2020 14:06:08 +0300

> From: Markus Triska <triska <at> metalevel.at>
> Cc: 43506 <at> debbugs.gnu.org
> Date: Sat, 19 Sep 2020 12:07:24 +0200
> 
> Eli Zaretskii <eliz <at> 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).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: triska <at> metalevel.at
Cc: 43506 <at> debbugs.gnu.org
Subject: Re: bug#43506: 26.1;
 line-height sometimes has no effect on the line height
Date: Sat, 19 Sep 2020 14:43:26 +0300

> Date: Sat, 19 Sep 2020 14:06:08 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 43506 <at> debbugs.gnu.org
> 
> > From: Markus Triska <triska <at> metalevel.at>
> > Cc: 43506 <at> debbugs.gnu.org
> > Date: Sat, 19 Sep 2020 12:07:24 +0200
> > 
> > Eli Zaretskii <eliz <at> 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.

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

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43506 <at> debbugs.gnu.org
Subject: Re: bug#43506: 26.1;
 line-height sometimes has no effect on the line height
Date: Sat, 19 Sep 2020 13:43:53 +0200

Eli Zaretskii <eliz <at> 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

Message #27 received at 43506-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43506-done <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#43506: 26.1;
 line-height sometimes has no effect on the line height
Date: Mon, 10 Feb 2025 23:22:47 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Sat, 19 Sep 2020 14:06:08 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: 43506 <at> debbugs.gnu.org
>>
>> > From: Markus Triska <triska <at> metalevel.at>
>> > Cc: 43506 <at> debbugs.gnu.org
>> > Date: Sat, 19 Sep 2020 12:07:24 +0200
>> >
>> > Eli Zaretskii <eliz <at> 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.

No further comments within 4 years.

I'm therefore closing this bug report.

Message #30 received at 43506-done <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 43506-done <at> debbugs.gnu.org
Subject: Re: bug#43506: 26.1;
 line-height sometimes has no effect on the line height
Date: Tue, 11 Feb 2025 19:04:15 +0100

Stefan Kangas <stefankangas <at> gmail.com> writes:

> No further comments within 4 years.
>
> I'm therefore closing this bug report.

I understand that you, as maintainers, close an existing report if you
do not consider at an issue. However, if there is any need to reconfirm
an existing issue every 4 years, then please consider this reply as such
reconfirmation.

Thank you and all the best,
Markus

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Markus Triska <triska <at> metalevel.at>
Cc: 43506 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#43506: 26.1;
 line-height sometimes has no effect on the line height
Date: Tue, 11 Feb 2025 10:25:48 -0800

Markus Triska <triska <at> metalevel.at> writes:

> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> No further comments within 4 years.
>>
>> I'm therefore closing this bug report.
>
> I understand that you, as maintainers, close an existing report if you
> do not consider at an issue. However, if there is any need to reconfirm
> an existing issue every 4 years, then please consider this reply as such
> reconfirmation.

There is generally no reason to reconfirm issues every 4 years, no.
I closed it because of this quote from Eli:

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

The previous discussion suggested that this is not a bug, but is working
as expected.  Since there had been no followups to that direct quote, I
assumed that this settled the matter.

If you still believe there's a bug here, could you please reply to the
points made by Eli in his last reply on 2020-09-19 with a rationale?

Thanks in advance.

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

From: Markus Triska <triska <at> metalevel.at>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 43506 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#43506: 26.1;
 line-height sometimes has no effect on the line height
Date: Tue, 11 Feb 2025 20:56:06 +0100

Stefan Kangas <stefankangas <at> gmail.com> writes:

> The previous discussion suggested that this is not a bug, but is working
> as expected.  Since there had been no followups to that direct quote, I
> assumed that this settled the matter.

Yes thank you, that is a completely understandable reason to close this:
The behaviour I describe here is intended.

Thank you and all the best,
Markus

Previous Next

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