GNU bug report logs - #23806
24.5; can not set 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 23806 in the body.
You can then email your comments to 23806 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: ynyaaa <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 24.5; can not set line height
Date: Mon, 20 Jun 2016 11:15:11 +0900

`line-height' property is effective only at the newlines,
so there are no chances to set line height
  (1) when the line is wrapped
  (2) when the line is truncated
  (3) when the line is at the bottom of a buffer
        and not terminated by newline



In GNU Emacs 24.5.1 (i686-pc-mingw32)
 of 2015-04-11 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.0.6002
Configured using:
 `configure --prefix=/c/usr --host=i686-pc-mingw32'

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

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-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:

Quit

Load-path shadows:
None found.

Features:
(network-stream starttls tls mailalias smtpmail warnings auth-source
eieio byte-opt bytecomp byte-compile cl-extra cconv eieio-core
password-cache shadow sort gnus-util mail-extr emacsbug message
format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils advice debug help-fns mule-util
pp wid-edit cl-loaddefs cl-lib descr-text help-mode easymenu time-date
japan-util tooltip electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer 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 make-network-process
w32notify w32 multi-tty emacs)

Memory information:
((conses 8 227072 60329)
 (symbols 32 29503 0)
 (miscs 32 99 569)
 (strings 16 27899 6877)
 (string-bytes 1 690788)
 (vectors 8 25909)
 (vector-slots 4 789072 15730)
 (floats 8 67 702)
 (intervals 28 717 199)
 (buffers 508 22))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 23806 <at> debbugs.gnu.org
Subject: Re: bug#23806: 24.5; can not set line height
Date: Mon, 20 Jun 2016 17:36:27 +0300

tags 23806 + notabug
thanks

> From: ynyaaa <at> gmail.com
> Date: Mon, 20 Jun 2016 11:15:11 +0900
> 
> `line-height' property is effective only at the newlines,
> so there are no chances to set line height
>   (1) when the line is wrapped
>   (2) when the line is truncated
>   (3) when the line is at the bottom of a buffer
>         and not terminated by newline

Yes.  As clearly documented in the ELisp manual:

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

It talks about "display lines", not physical lines.

The line-height property you put on a newline is designed and
implemented to cater to a specific use case: to allow control of the
effect the newline itself has on the line height.  Since the newline
only affects the height of the display line that ends in that newline,
this is what this feature supports.  It is not a general-purpose way
of controlling the vertical spacing of lines on display.

The node "Line Height" in the ELisp manual describes the line-spacing
variable and frame parameter, which are more general-purpose ways of
controlling vertical layout of text.

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

From: ynyaaa <at> gmail.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23806 <at> debbugs.gnu.org
Subject: Re: bug#23806: 24.5; can not set line height
Date: Tue, 21 Jun 2016 10:45:10 +0900

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

> The node "Line Height" in the ELisp manual describes the line-spacing
> variable and frame parameter, which are more general-purpose ways of
> controlling vertical layout of text.

The manual also describes the line-spacing property at the newlines,
which has same problems as the line-height property.

I want to use the line-height property because the line-spacing variable
can not affect partial buffer contents and can not add spacing both
above and below lines.


By the way it is written in the manual,
       If the property value is a list of the form ‘(HEIGHT TOTAL)’,
    (snip) In
    this case, the other ways to specify the line spacing are ignored.

Setting the line-height property to '(1.0 1.0) ignores the line-spacing
property, but the line-spacing variable or frame parameter takes effect.

Setting the line-height property to 't ignores the line-spacing
property, this behavior is not documented.


In the manual:
       Finally, a newline can have a ‘line-spacing’ text or overlay property
    that overrides the default frame line spacing and the buffer local
    ‘line-spacing’ variable, for the display line ending in that newline.

The line-spacing property overrides the line-spacing variable or frame
parameter only if the property value is bigger.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: ynyaaa <at> gmail.com
Cc: 23806-done <at> debbugs.gnu.org
Subject: Re: bug#23806: 24.5; can not set line height
Date: Tue, 21 Jun 2016 17:24:54 +0300

> From: ynyaaa <at> gmail.com
> Cc: 23806 <at> debbugs.gnu.org
> Date: Tue, 21 Jun 2016 10:45:10 +0900
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > The node "Line Height" in the ELisp manual describes the line-spacing
> > variable and frame parameter, which are more general-purpose ways of
> > controlling vertical layout of text.
> 
> The manual also describes the line-spacing property at the newlines,
> which has same problems as the line-height property.

Yes, and its documentation also refers to a "display line".

> I want to use the line-height property because the line-spacing variable
> can not affect partial buffer contents

What do you mean by "partial buffer contents"?

> and can not add spacing both above and below lines.

Such an extension could be added.

> By the way it is written in the manual,
>        If the property value is a list of the form ‘(HEIGHT TOTAL)’,
>     (snip) In
>     this case, the other ways to specify the line spacing are ignored.
> 
> Setting the line-height property to '(1.0 1.0) ignores the line-spacing
> property, but the line-spacing variable or frame parameter takes effect.
> 
> Setting the line-height property to 't ignores the line-spacing
> property, this behavior is not documented.

It's documented, sort of, by saying that only the visible content
determines the line height in this case.  But I made that more
explicit.

> In the manual:
>        Finally, a newline can have a ‘line-spacing’ text or overlay property
>     that overrides the default frame line spacing and the buffer local
>     ‘line-spacing’ variable, for the display line ending in that newline.
> 
> The line-spacing property overrides the line-spacing variable or frame
> parameter only if the property value is bigger.

Actually, it doesn't override, but compared, and the largest value
used instead.

I fixed these inaccuracies, and I'm marking the bug done.

Thanks.

Previous Next

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