bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Feng Shu]

Hi

I have try the below code, and it work
 
   (insert (propertize "\n" 'line-height 1.4))
 
But how to apply line-height global and let line-height work with
mode/header/tab-bar?  

Maybe we should add a variable or frame parameter: line-height



In GNU Emacs 29.0.50 (build 13, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-11-13 built on tumashu
Repository revision: f7abc04c4002a2fc7dc7c8c9ec2a264e25aaf5f5
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure --with-native-compilation --with-xwidgets --with-modules'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: zh_CN.UTF-8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix

Major mode: Message

Minor modes in effect:
  gnus-message-citation-mode: t
  marginalia-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  projectile-mode: t
  global-git-commit-mode: t
  mml-mode: t
  magit-auto-revert-mode: t
  emms-playing-time-display-mode: t
  emms-playing-time-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  company-posframe-mode: t
  global-company-mode: t
  org-super-agenda-mode: t
  shell-dirtrack-mode: t
  pyim-isearch-mode: t
  vertico-mode: t
  savehist-mode: t
  global-tab-line-mode: t
  tab-line-mode: t
  global-so-long-mode: t
  electric-pair-mode: t
  recentf-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  context-menu-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
  auto-fill-function: yas--auto-fill
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
/home/feng/.emacs.d/elpa-29/transient-20211105.100/transient hides /home/feng/project/emacs/lisp/transient

Features:
(magit-extras vc-mtn vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs
citre-lang-c cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs tramp-archive tramp-gvfs tramp-cache
zeroconf wgrep find-dired vc-git bug-reference jka-compr shadow emacsbug
mailalias smtpmail sendmail mail-extr gnus-async gnus-bcklg gnus-ml
hl-line utf-7 imap rfc2104 qp gnutls network-stream nsm pop3 epa-file
nndraft nnmh nnml eh-gnus-common gnus-select-account eww xdg url-queue
mm-url gnus-demon gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg nntp gnus-cite gnus-art mm-uu mml2015 mm-view mml-smime smime
dig gnus-cache gnus-sum shr kinsoku svg dom gnus-group gnus-undo eh-gnus
gnus-start gnus-dbus dbus gnus-cloud nnimap nnmail mail-source utf7
netrc nnoo gnus-spec gnus-int gnus-range gnus-win gnus nnheader
marginalia cus-start vertico-posframe cl-print mule-util misearch
multi-isearch cursor-sensor pyim-dhashcache async eieio-opt speedbar
ezimage dframe shortdoc help-fns radix-tree citre citre-peek
citre-basic-tools citre-ctags emacs-helper eh-misc undo-tree xwidget
image-mode exif projectile lisp-mnt grep ibuf-ext ibuffer
ibuffer-loaddefs magit-bookmark magit-submodule magit-obsolete
magit-popup magit-blame magit-stash magit-reflog magit-bisect magit-push
magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff
smerge-mode diff diff-mode git-commit log-edit message yank-media rmc
puny rfc822 mml mml-sec epa gnus-util rmail rmail-loaddefs mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util add-log magit-core magit-autorevert magit-margin
magit-transient magit-process with-editor server magit-mode transient
edmacro magit-git magit-section magit-utils crm gitpatch
aggressive-indent eh-emms emms-librefm-stream xml emms-librefm-scrobbler
emms-playlist-limit emms-i18n emms-history emms-score emms-stream-info
emms-metaplaylist-mode emms-bookmarks emms-cue emms-mode-line-icon
emms-player-xine emms-player-mpd tq emms-lyrics emms-url emms-streams
emms-show-all emms-tag-editor emms-tag-tracktag emms-mark emms-mode-line
emms-info-tinytag emms-info-metaflac emms-info-opusinfo
emms-info-ogginfo emms-info-mp3info emms-player-vlc emms-player-mpv
emms-playing-time emms-player-mplayer emms-player-simple emms-browser
sort emms-playlist-sort emms-last-played emms-volume
emms-volume-sndioctl emms-volume-mixerctl emms-volume-pulse
emms-volume-amixer emms-playlist-mode emms-source-playlist
emms-source-file locate emms-cache emms-info-native bindat
emms-info-exiftool emms-info emms-later-do emms-setup emms emms-compat
epg rfc6068 epg-config el2org cnfonts cnfonts-ui cus-edit cus-load
thingatpt yasnippet vterm face-remap compile color term disp-table ehelp
vterm-module term/xterm xterm citre-config citre-lang-fileref citre-util
citre-core citre-tag citre-core-tables citre-common eh-complete
company-posframe company-keywords company-etags etags fileloop xref
project company-gtags company-template company-dabbrev-code
company-dabbrev company-files company-capf company eh-org
org-super-agenda ts ht s org-habit ob-python python tramp-sh tramp
tramp-loaddefs trampver tramp-integration files-x tramp-compat shell
parse-time ls-lisp ob-org ob-plantuml ox-extra ox-md ox-org ox-odt
rng-loc rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse
nxml-ns nxml-enc xmltok nxml-util ox-latex ox-icalendar org-agenda
ox-html table ox-ascii ox-publish ox org-element avl-tree generator
org-protocol autorevert filenotify org-attach org-id org-refile org ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-src
ob-comint org-pcomplete pcomplete comint ansi-color org-list org-faces
org-entities noutline outline org-version ob-emacs-lisp ob-core ob-eval
org-table oc-basic bibtex iso8601 time-date ol org-keys oc org-compat
advice org-macs org-loaddefs format-spec find-func eh-functions eh-theme
modus-vivendi-theme modus-operandi-theme modus-themes eh-basic
cal-china-x cal-china lunar solar cal-dst holidays hol-loaddefs cal-menu
calendar cal-loaddefs pyim-liberime liberime liberime-core pyim
pyim-hacks pyim-probe pyim-cregexp pcase xr pyim-process pyim-cstring
pyim-autoselector pyim-punctuation pyim-outcome pyim-indicator
pyim-preview pyim-magic pyim-candidates pyim-codes pyim-imobjs
pyim-pinyin pyim-pymap pyim-dcache pyim-dict derived pyim-page
pyim-entered popup posframe pyim-scheme pyim-common dired-ranger ring
dired-hacks-utils dash wdired dired dired-loaddefs vc vc-dispatcher
consult-vertico consult kmacro orderless vertico savehist tab-line
switch-window switch-window-mvborder switch-window-asciiart quail
so-long elec-pair bookmark text-property-search pp recentf tree-widget
wid-edit elpa-mirror finder-inf tex-site kotl-autoloads easy-mmode info
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap url-handlers
url-parse auth-source eieio eieio-core eieio-loaddefs password-cache
json map url-vars comp comp-cstr warnings rx cl-seq cl-macs cl-extra seq
gv subr-x byte-opt bytecomp byte-compile cconv help-mode cl-loaddefs
cl-lib china-util iso-transl tooltip eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer 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 composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 1057759 285023)
 (symbols 48 56580 305)
 (strings 32 335937 20594)
 (string-bytes 1 9305391)
 (vectors 16 108204)
 (vector-slots 8 14153970 256247)
 (floats 8 1326 1594)
 (intervals 56 3943 2048)
 (buffers 992 42))

-- 

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

"Feng Shu" <tumashu@163.com> writes:

> Maybe we should add a variable or frame parameter: line-height

Sounds good to me.  Perhaps call it min{imum,}-line-height, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Feng Shu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Feng Shu" <tumashu@163.com> writes:
>
>> Maybe we should add a variable or frame parameter: line-height
>
> Sounds good to me.  Perhaps call it min{imum,}-line-height, though.
good idea.

-- 

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 14 Nov 2021 02:23:46 +0100
> Cc: 51821@debbugs.gnu.org
> 
> "Feng Shu" <tumashu@163.com> writes:
> 
> > Maybe we should add a variable or frame parameter: line-height
> 
> Sounds good to me.  Perhaps call it min{imum,}-line-height, though.

IMO it should be line-height, for similarity with line-spacing.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Sounds good to me.  Perhaps call it min{imum,}-line-height, though.
>
> IMO it should be line-height, for similarity with line-spacing.

But line-spacing is an absolute value, while this isn't an absolute
line-height.  If there's something that's taller than line-height, the
line won't be truncated to that value.

So it's the minimum line height.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Feng Shu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Sounds good to me.  Perhaps call it min{imum,}-line-height, though.
>>
>> IMO it should be line-height, for similarity with line-spacing.
>
> But line-spacing is an absolute value, while this isn't an absolute
> line-height.  If there's something that's taller than line-height, the
> line won't be truncated to that value.
>
> So it's the minimum line height.

Does line-height exist in emacs just mean min line height? I do not know.

-- 

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tumashu@163.com,  51821@debbugs.gnu.org
> Date: Sun, 14 Nov 2021 08:01:36 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Sounds good to me.  Perhaps call it min{imum,}-line-height, though.
> >
> > IMO it should be line-height, for similarity with line-spacing.
> 
> But line-spacing is an absolute value, while this isn't an absolute
> line-height.  If there's something that's taller than line-height, the
> line won't be truncated to that value.
> 
> So it's the minimum line height.

How is this different from the line-height text property?

I think it will be confusing and harder to remember to have
line-spacing both as a variable and a text property, but line-height
only as a text property with a variable named differently.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  51821@debbugs.gnu.org
> Date: Sun, 14 Nov 2021 15:04:37 +0800
> 
> Does line-height exist in emacs just mean min line height? I do not know.

Yes.  The ELisp manual clearly says (note the last sentence):

     Thus, any valid height spec determines the height in pixels, one way
  or another.  If the line contents’ height is less than that, Emacs adds
  extra vertical space above the line to achieve the specified total
  height.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Date: Sun, 14 Nov 2021 07:28:46 +0800
> 
> I have try the below code, and it work
>  
>    (insert (propertize "\n" 'line-height 1.4))
>  
> But how to apply line-height global and let line-height work with
> mode/header/tab-bar?  
> 
> Maybe we should add a variable or frame parameter: line-height

Adding a variable is easy, but what would be its semantics?  Emacs can
display different faces in the same window, and some of those faces
can have smaller height.  If the line of text in a window uses the
smaller faces, that line's height will be smaller as well.

For example, evaluate the following:

  (defface small
    '((t :height 0.6))
    "")

Then visit some file, and do this:

  M-x font-lock-mode RET
  M-x load-library RET facemenu RET
  C-SPC
  C-n
  C-n
  M-x facemenu-set-face RET small RET

Now you should see 2 lines in a smaller font; those lines have
correspondingly smaller height.

So if we require all the lines to be at least line-height pixels,
those smaller lines will also become higher, and that is not what's
expected, I guess?

So what would be the correct interpretation of the line-height
variable or frame parameter, when different faces are being used?

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> So what would be the correct interpretation of the line-height
> variable or frame parameter, when different faces are being used?

I think...  a natural interpretation would be that explicit :height
specs would override the line-height variable/parameter?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: "Feng Shu" <tumashu@163.com>,  51821@debbugs.gnu.org
> Date: Sun, 14 Nov 2021 18:55:38 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So what would be the correct interpretation of the line-height
> > variable or frame parameter, when different faces are being used?
> 
> I think...  a natural interpretation would be that explicit :height
> specs would override the line-height variable/parameter?

But line-height is not a variable or parameter, it is just a text
property, and it needs to be put on a newline to change the height of
that single line.  So currently this is up to the Lisp program: if it
puts this property on some line, the visual results is its
responsibility.

By contrast, a buffer-local variable or a frame parameter are global:
they apply to all lines, tall and small alike.  And users will use
this variable/parameter globally as well.  Thus its effect on lines
that use smaller fonts is something to be concerned about.

My impression is that this is wanted only for the default face, and
then only for the ASCII font of that face.  That could be done, I
think, but (a) it will probably not work with text-scaling and other
remappings of the default faces, and (b) some faces other than default
also need this, definitely the mode-line and header-line, but also
fixed-pitch perhaps?

So I'm stuck trying to figure out what exactly are the requirements
here.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Feng Shu" <tumashu@163.com>
>> Date: Sun, 14 Nov 2021 07:28:46 +0800
>> 
>> I have try the below code, and it work
>>  
>>    (insert (propertize "\n" 'line-height 1.4))
>>  
>> But how to apply line-height global and let line-height work with
>> mode/header/tab-bar?  
>> 
>> Maybe we should add a variable or frame parameter: line-height
>
> Adding a variable is easy, but what would be its semantics?  Emacs can
> display different faces in the same window, and some of those faces
> can have smaller height.  If the line of text in a window uses the
> smaller faces, that line's height will be smaller as well.
>
> For example, evaluate the following:
>
>   (defface small
>     '((t :height 0.6))
>     "")
>
> Then visit some file, and do this:
>
>   M-x font-lock-mode RET
>   M-x load-library RET facemenu RET
>   C-SPC
>   C-n
>   C-n
>   M-x facemenu-set-face RET small RET
>
> Now you should see 2 lines in a smaller font; those lines have
> correspondingly smaller height.

I think user should set to (t . RATIO) instead in most case.

Maybe line-height can be a alist ((face1 . RATIO) (face2 .RATIO)).


  ‘(FACE . RATIO)’
     If the height spec is a cons of the format shown, the numeric
     height is RATIO times the height of face FACE.  RATIO can be any
     type of number, or ‘nil’ which means a ratio of 1.  If FACE is ‘t’,
     it refers to the current face.


>
> So if we require all the lines to be at least line-height pixels,
> those smaller lines will also become higher, and that is not what's
> expected, I guess?

If user set line-height to a INTEGER with a variable, I think it
is user expected.


>
> So what would be the correct interpretation of the line-height
> variable or frame parameter, when different faces are being used?

-- 

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: "Feng Shu" <tumashu@163.com>,  51821@debbugs.gnu.org
>> Date: Sun, 14 Nov 2021 18:55:38 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > So what would be the correct interpretation of the line-height
>> > variable or frame parameter, when different faces are being used?
>> 
>> I think...  a natural interpretation would be that explicit :height
>> specs would override the line-height variable/parameter?
>
> But line-height is not a variable or parameter, it is just a text
> property, and it needs to be put on a newline to change the height of
> that single line.  So currently this is up to the Lisp program: if it
> puts this property on some line, the visual results is its
> responsibility.
>
> By contrast, a buffer-local variable or a frame parameter are global:
> they apply to all lines, tall and small alike.  And users will use
> this variable/parameter globally as well.  Thus its effect on lines
> that use smaller fonts is something to be concerned about.
>
> My impression is that this is wanted only for the default face, and
> then only for the ASCII font of that face.  That could be done, I
> think, but (a) it will probably not work with text-scaling and other
> remappings of the default faces, and (b) some faces other than default
> also need this, definitely the mode-line and header-line, but also
> fixed-pitch perhaps?
>
> So I'm stuck trying to figure out what exactly are the requirements
> here.

What about support it as a face attr instead of variable?


-- 

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> How is this different from the line-height text property?
>
> I think it will be confusing and harder to remember to have
> line-spacing both as a variable and a text property, but line-height
> only as a text property with a variable named differently.

I was only thinking about this in relation to the line-spacing variable.
But, yes, calling the variable line-height to reflect the symmetry with
the text property makes sense.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think...  a natural interpretation would be that explicit :height
>> specs would override the line-height variable/parameter?
>
> But line-height is not a variable or parameter, it is just a text
> property, and it needs to be put on a newline to change the height of
> that single line.  So currently this is up to the Lisp program: if it
> puts this property on some line, the visual results is its
> responsibility.

I was talking about the line-height variable only here, not the text
property.

> By contrast, a buffer-local variable or a frame parameter are global:
> they apply to all lines, tall and small alike.  And users will use
> this variable/parameter globally as well.  Thus its effect on lines
> that use smaller fonts is something to be concerned about.
>
> My impression is that this is wanted only for the default face, and
> then only for the ASCII font of that face.  That could be done, I
> think, but (a) it will probably not work with text-scaling and other
> remappings of the default faces, and (b) some faces other than default
> also need this, definitely the mode-line and header-line, but also
> fixed-pitch perhaps?
>
> So I'm stuck trying to figure out what exactly are the requirements
> here.

It has to work across different fonts -- I think that's the real use
case here, that if you're missing different fonts (which you commonly
are when writing with different scripts), then the Emacs display gets
pretty messy (uneven line heights all over the place).

So here's how I think the `line-height' variable should work:

* After redisplay has composed a line, it should check whether the line
height is less than `line-height', and if so, add empty space at the
bottom (or the top, or perhaps both, to center it).

** But -- if the line is composed purely of text with a face with an
   explicit :height property, it should do nothing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: 51821@debbugs.gnu.org
> Date: Mon, 15 Nov 2021 06:37:23 +0800
> 
> I think user should set to (t . RATIO) instead in most case.
> 
> Maybe line-height can be a alist ((face1 . RATIO) (face2 .RATIO)).
> 
> 
>   ‘(FACE . RATIO)’
>      If the height spec is a cons of the format shown, the numeric
>      height is RATIO times the height of face FACE.  RATIO can be any
>      type of number, or ‘nil’ which means a ratio of 1.  If FACE is ‘t’,
>      it refers to the current face.

No, I don't think RATIO can solve the problem, because it will cause
both the ASCII and the Chinese fonts to be enlarged, and you will
again see the same problem.

AFAIU, you explicitly want to have _different_ behavior with ASCII and
Chinese fonts of the default face, and that cannot be handled on the
face level, because on that level we cannot distinguish between the
two fonts.

> > So if we require all the lines to be at least line-height pixels,
> > those smaller lines will also become higher, and that is not what's
> > expected, I guess?
> 
> If user set line-height to a INTEGER with a variable, I think it
> is user expected.

I don't think it's wise to provide features that trip naïve users and
then tell them "you asked for it".  It won't be appreciated, and we
will have bug reports.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  51821@debbugs.gnu.org
> Date: Mon, 15 Nov 2021 06:42:39 +0800
> 
> What about support it as a face attr instead of variable?

I explained in a previous message why this cannot work at the face
level.

Anyway, we should first think about what the feature will do, not how
to specify it.  How to specify it will come next.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tumashu@163.com,  51821@debbugs.gnu.org
> Date: Mon, 15 Nov 2021 06:39:15 +0100
> 
> It has to work across different fonts -- I think that's the real use
> case here, that if you're missing different fonts (which you commonly
> are when writing with different scripts), then the Emacs display gets
> pretty messy (uneven line heights all over the place).

You mean, because of "tofu"?  But tofu doesn't change the line height,
AFAIK.  So I think I'm missing something.

> * After redisplay has composed a line, it should check whether the line
> height is less than `line-height', and if so, add empty space at the
> bottom (or the top, or perhaps both, to center it).
> 
> ** But -- if the line is composed purely of text with a face with an
>    explicit :height property, it should do nothing.

The last part ruins it all.  I guess you are thinking about faces in
their 'defface' form?  But when a face gets to be used by the display
code, it is converted to the internal form and always completely
specified, and thus always has an explicit :height property already
calculated.  And of course the default face must always be completely
specified at this point.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Feng Shu" <tumashu@163.com>
>> Cc: 51821@debbugs.gnu.org
>> Date: Mon, 15 Nov 2021 06:37:23 +0800
>> 
>> I think user should set to (t . RATIO) instead in most case.
>> 
>> Maybe line-height can be a alist ((face1 . RATIO) (face2 .RATIO)).
>> 
>> 
>>   ‘(FACE . RATIO)’
>>      If the height spec is a cons of the format shown, the numeric
>>      height is RATIO times the height of face FACE.  RATIO can be any
>>      type of number, or ‘nil’ which means a ratio of 1.  If FACE is ‘t’,
>>      it refers to the current face.
>
> No, I don't think RATIO can solve the problem, because it will cause
> both the ASCII and the Chinese fonts to be enlarged, and you will
> again see the same problem.
>
> AFAIU, you explicitly want to have _different_ behavior with ASCII and
> Chinese fonts of the default face, and that cannot be handled on the

This is not my final purpose, I just want to mode/head/tab line and
minibuffer's height do not change depend on Chinese char exist or not.

The reason I care line-height is that it can control
mode/head/tab-line/minibuffer's height.

> face level, because on that level we cannot distinguish between the
> two fonts.



>
>> > So if we require all the lines to be at least line-height pixels,
>> > those smaller lines will also become higher, and that is not what's
>> > expected, I guess?
>> 
>> If user set line-height to a INTEGER with a variable, I think it
>> is user expected.
>
> I don't think it's wise to provide features that trip naïve users and
> then tell them "you asked for it".  It won't be appreciated, and we
> will have bug reports.

Sounds reasonable 

-- 

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> It has to work across different fonts -- I think that's the real use
>> case here, that if you're missing different fonts (which you commonly
>> are when writing with different scripts), then the Emacs display gets
>> pretty messy (uneven line heights all over the place).
>
> You mean, because of "tofu"?  But tofu doesn't change the line height,
> AFAIK.  So I think I'm missing something.

No, because they're using a mix of different fonts with different heights.

> The last part ruins it all.  I guess you are thinking about faces in
> their 'defface' form?  But when a face gets to be used by the display
> code, it is converted to the internal form and always completely
> specified, and thus always has an explicit :height property already
> calculated.  And of course the default face must always be completely
> specified at this point.

We can propagate the :height setting into the face object as
:requested-height or something.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tumashu@163.com,  51821@debbugs.gnu.org
> Date: Tue, 16 Nov 2021 08:34:23 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> It has to work across different fonts -- I think that's the real use
> >> case here, that if you're missing different fonts (which you commonly
> >> are when writing with different scripts), then the Emacs display gets
> >> pretty messy (uneven line heights all over the place).
> >
> > You mean, because of "tofu"?  But tofu doesn't change the line height,
> > AFAIK.  So I think I'm missing something.
> 
> No, because they're using a mix of different fonts with different heights.

That shouldn't happen, normally.  Emacs selects fonts of the same size
for a face.  Maybe people force different sizes, via fontsets or some
similar customizations, because of the issue with pixel-width of
double-width characters, but then this is not a general problem with
mixing fonts in the same face.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 170 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> That shouldn't happen, normally.  Emacs selects fonts of the same size
> for a face.

No, not really.  Here's a trivial example:


[-- Attachment #2: Type: image/png, Size: 117981 bytes --]

[-- Attachment #3: Type: text/plain, Size: 446 bytes --]


Note how the lines with jidanni are taller than the rest.

> Maybe people force different sizes, via fontsets or some
> similar customizations, because of the issue with pixel-width of
> double-width characters, but then this is not a general problem with
> mixing fonts in the same face.

This is with the default font selection mechanism.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tumashu@163.com,  51821@debbugs.gnu.org
> Date: Tue, 16 Nov 2021 16:20:52 +0100
> 
> > That shouldn't happen, normally.  Emacs selects fonts of the same size
> > for a face.
> 
> No, not really.  Here's a trivial example:
> 
> 
> Note how the lines with jidanni are taller than the rest.

OK, let me see what can be done about that.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> Date: Tue, 16 Nov 2021 18:45:16 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: tumashu@163.com, 51821@debbugs.gnu.org
> 
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: tumashu@163.com,  51821@debbugs.gnu.org
> > Date: Tue, 16 Nov 2021 16:20:52 +0100
> > 
> > > That shouldn't happen, normally.  Emacs selects fonts of the same size
> > > for a face.
> > 
> > No, not really.  Here's a trivial example:
> > 
> > 
> > Note how the lines with jidanni are taller than the rest.
> 
> OK, let me see what can be done about that.

Please try the patch below.  I have a very limited number of cases
with which I can test it, so I think users of CJK scripts should say
what they think.  Basically, set the new variable line-height-factor
to something like 1.2 (more if you enlarge the non-ASCII font to make
double-width characters take close to 2 columns), and see if you get
the desired effect.

If this is what people want, I will install it and document it.

diff --git a/src/window.c b/src/window.c
index e801ff8..a368b6d 100644
--- a/src/window.c
+++ b/src/window.c
@@ -5246,7 +5246,10 @@ grow_mini_window (struct window *w, int delta)
 {
   struct frame *f = XFRAME (w->frame);
   int old_height = window_body_height (w, true);
-  int min_height = FRAME_LINE_HEIGHT (f);
+  int min_height =
+    FLOATP (Vline_height_factor)
+    ? FRAME_LINE_HEIGHT (f) * XFLOAT_DATA (Vline_height_factor)
+    : FRAME_LINE_HEIGHT (f);
 
   eassert (MINI_WINDOW_P (w));
 
@@ -5279,7 +5282,11 @@ grow_mini_window (struct window *w, int delta)
 shrink_mini_window (struct window *w)
 {
   struct frame *f = XFRAME (w->frame);
-  int delta = window_body_height (w, true) - FRAME_LINE_HEIGHT (f);
+  int min_line_height =
+    FLOATP (Vline_height_factor)
+    ? FRAME_LINE_HEIGHT (f) * XFLOAT_DATA (Vline_height_factor)
+    : FRAME_LINE_HEIGHT (f);
+  int delta = window_body_height (w, true) - min_line_height;
 
   eassert (MINI_WINDOW_P (w));
 
diff --git a/src/xdisp.c b/src/xdisp.c
index ef49297..d1f4043 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -22073,6 +22073,18 @@ append_space_for_newline (struct it *it, bool default_face_p)
 		  it->descent = it->override_descent;
 		  boff = it->override_boff;
 		}
+	      else
+		{
+		  /* Enlarge the ascent to make the row higher by
+		     line-height-factor if needed.  */
+		  if (face == face->ascii_face && it->voffset == 0
+		      && FLOATP (Vline_height_factor))
+		    {
+		      int enlarged_height = ((it->ascent + it->descent)
+					     * XFLOAT_DATA (Vline_height_factor));
+		      it->ascent = enlarged_height - it->descent;
+		    }
+		}
 	      if (EQ (height, Qt))
 		extra_line_spacing = 0;
 	      else
@@ -30587,9 +30599,9 @@ gui_produce_glyphs (struct it *it)
 	  /* When no suitable font is found, display this character by
 	     the method specified in the first extra slot of
 	     Vglyphless_char_display.  */
-	      Lisp_Object acronym = lookup_glyphless_char_display (-1, it);
+	  Lisp_Object acronym = lookup_glyphless_char_display (-1, it);
 
-	      eassert (it->what == IT_GLYPHLESS);
+	  eassert (it->what == IT_GLYPHLESS);
 	  produce_glyphless_glyph (it, true,
 				   STRINGP (acronym) ? acronym : Qnil);
 	  goto done;
@@ -30613,6 +30625,15 @@ gui_produce_glyphs (struct it *it)
  	    {
  	      it->ascent = FONT_BASE (font) + boff;
  	      it->descent = FONT_DESCENT (font) - boff;
+	      /* If this glyph uses the ASCII face, enlarge the ascent
+		 to make the row higher by line-height-factor.  */
+	      if (face == face->ascii_face && it->voffset == 0
+		  && FLOATP (Vline_height_factor))
+		{
+		  int enlarged_height = ((it->ascent + it->descent)
+					 * XFLOAT_DATA (Vline_height_factor));
+		  it->ascent = enlarged_height - it->descent;
+		}
  	    }
 
 	  if (get_char_glyph_code (it->char_to_display, font, &char2b))
@@ -30763,6 +30784,13 @@ gui_produce_glyphs (struct it *it)
 		{
 		  it->ascent = FONT_BASE (font) + boff;
 		  it->descent = FONT_DESCENT (font) - boff;
+		  if (face == face->ascii_face && it->voffset == 0
+		      && FLOATP (Vline_height_factor))
+		    {
+		      int enlarged_height = ((it->ascent + it->descent)
+					     * XFLOAT_DATA (Vline_height_factor));
+		      it->ascent = enlarged_height - it->descent;
+		    }
 		}
 	    }
 
@@ -30886,6 +30914,13 @@ gui_produce_glyphs (struct it *it)
 		{
 		  it->ascent = FONT_BASE (font) + boff;
 		  it->descent = FONT_DESCENT (font) - boff;
+		  if (face == face->ascii_face && it->voffset == 0
+		      && FLOATP (Vline_height_factor))
+		    {
+		      int enlarged_height = ((it->ascent + it->descent)
+					     * XFLOAT_DATA (Vline_height_factor));
+		      it->ascent = enlarged_height - it->descent;
+		    }
 		}
 	      it->phys_ascent = it->ascent;
 	      it->phys_descent = it->descent;
@@ -31243,6 +31278,24 @@ gui_produce_glyphs (struct it *it)
 	  if (it->glyph_row
 	      && (metrics.lbearing < 0 || metrics.rbearing > metrics.width))
 	    it->glyph_row->contains_overlapping_glyphs_p = true;
+	  if (it->voffset == 0 && FLOATP (Vline_height_factor))
+	    {
+	      Lisp_Object font_object = LGSTRING_FONT (gstring);
+	      struct font *gstring_font = XFONT_OBJECT (font_object);
+
+	      /* This is for when the grapheme cluster displays some
+		 ligature using ASCII font: if the height is smaller
+		 than line-height-factor says, enlarge the ascent.  */
+	      if (face == face->ascii_face
+		  && face->ascii_face->font == gstring_font)
+		{
+		  int enlarged_height =
+		    ((FONT_BASE (gstring_font) + FONT_DESCENT (gstring_font))
+		     * XFLOAT_DATA (Vline_height_factor));
+		  if (metrics.ascent + metrics.descent < enlarged_height)
+		    metrics.ascent = enlarged_height - metrics.descent;
+		}
+	    }
 	  it->ascent = it->phys_ascent = metrics.ascent;
 	  it->descent = it->phys_descent = metrics.descent;
 	}
@@ -35581,6 +35634,16 @@ syms_of_xdisp (void)
 mini-window frame's default font's height.  */);
   Vmax_mini_window_height = make_float (0.25);
 
+  DEFVAR_LISP ("line-height-factor", Vline_height_factor,
+    doc: /* Factor for enlarging the height of lines that use the default font.
+The value should be a float number greater than 1.  It determines how
+much will Emacs enlarge the height of a screen line that shows only
+characters displayed with the default face's font for ASCII characters.
+This is to avoid differences in height between lines that use the
+ASCII font and those which use non-ASCII (for example, Chinese)
+font, which is typically higher than the ASCII one.  */);
+  Vline_height_factor = Qnil;
+
   DEFVAR_LISP ("resize-mini-windows", Vresize_mini_windows,
     doc: /* How to resize mini-windows (the minibuffer and the echo area).
 A value of nil means don't automatically resize mini-windows.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Please try the patch below.  I have a very limited number of cases
> with which I can test it, so I think users of CJK scripts should say
> what they think.  Basically, set the new variable line-height-factor
> to something like 1.2 (more if you enlarge the non-ASCII font to make
> double-width characters take close to 2 columns), and see if you get
> the desired effect.

Thanks, it seems to work well for what it's intended to.

> If this is what people want, I will install it and document it.

As for this, I have no specific opinion, as I didn't find the old
behavior problematic in the first place.  But thanks again!

> diff --git a/src/window.c b/src/window.c
> index e801ff8..a368b6d 100644
> --- a/src/window.c
> +++ b/src/window.c
> @@ -5246,7 +5246,10 @@ grow_mini_window (struct window *w, int delta)
>  {
>    struct frame *f = XFRAME (w->frame);
>    int old_height = window_body_height (w, true);
> -  int min_height = FRAME_LINE_HEIGHT (f);
> +  int min_height =
> +    FLOATP (Vline_height_factor)
> +    ? FRAME_LINE_HEIGHT (f) * XFLOAT_DATA (Vline_height_factor)
> +    : FRAME_LINE_HEIGHT (f);
>  
>    eassert (MINI_WINDOW_P (w));
>  
> @@ -5279,7 +5282,11 @@ grow_mini_window (struct window *w, int delta)
>  shrink_mini_window (struct window *w)
>  {
>    struct frame *f = XFRAME (w->frame);
> -  int delta = window_body_height (w, true) - FRAME_LINE_HEIGHT (f);
> +  int min_line_height =
> +    FLOATP (Vline_height_factor)
> +    ? FRAME_LINE_HEIGHT (f) * XFLOAT_DATA (Vline_height_factor)
> +    : FRAME_LINE_HEIGHT (f);
> +  int delta = window_body_height (w, true) - min_line_height;
>  
>    eassert (MINI_WINDOW_P (w));
>  
> diff --git a/src/xdisp.c b/src/xdisp.c
> index ef49297..d1f4043 100644
> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -22073,6 +22073,18 @@ append_space_for_newline (struct it *it, bool default_face_p)
>  		  it->descent = it->override_descent;
>  		  boff = it->override_boff;
>  		}
> +	      else
> +		{
> +		  /* Enlarge the ascent to make the row higher by
> +		     line-height-factor if needed.  */
> +		  if (face == face->ascii_face && it->voffset == 0
> +		      && FLOATP (Vline_height_factor))
> +		    {
> +		      int enlarged_height = ((it->ascent + it->descent)
> +					     * XFLOAT_DATA (Vline_height_factor));
> +		      it->ascent = enlarged_height - it->descent;
> +		    }
> +		}
>  	      if (EQ (height, Qt))
>  		extra_line_spacing = 0;
>  	      else
> @@ -30587,9 +30599,9 @@ gui_produce_glyphs (struct it *it)
>  	  /* When no suitable font is found, display this character by
>  	     the method specified in the first extra slot of
>  	     Vglyphless_char_display.  */
> -	      Lisp_Object acronym = lookup_glyphless_char_display (-1, it);
> +	  Lisp_Object acronym = lookup_glyphless_char_display (-1, it);
>  
> -	      eassert (it->what == IT_GLYPHLESS);
> +	  eassert (it->what == IT_GLYPHLESS);
>  	  produce_glyphless_glyph (it, true,
>  				   STRINGP (acronym) ? acronym : Qnil);
>  	  goto done;
> @@ -30613,6 +30625,15 @@ gui_produce_glyphs (struct it *it)
>   	    {
>   	      it->ascent = FONT_BASE (font) + boff;
>   	      it->descent = FONT_DESCENT (font) - boff;
> +	      /* If this glyph uses the ASCII face, enlarge the ascent
> +		 to make the row higher by line-height-factor.  */
> +	      if (face == face->ascii_face && it->voffset == 0
> +		  && FLOATP (Vline_height_factor))
> +		{
> +		  int enlarged_height = ((it->ascent + it->descent)
> +					 * XFLOAT_DATA (Vline_height_factor));
> +		  it->ascent = enlarged_height - it->descent;
> +		}
>   	    }
>  
>  	  if (get_char_glyph_code (it->char_to_display, font, &char2b))
> @@ -30763,6 +30784,13 @@ gui_produce_glyphs (struct it *it)
>  		{
>  		  it->ascent = FONT_BASE (font) + boff;
>  		  it->descent = FONT_DESCENT (font) - boff;
> +		  if (face == face->ascii_face && it->voffset == 0
> +		      && FLOATP (Vline_height_factor))
> +		    {
> +		      int enlarged_height = ((it->ascent + it->descent)
> +					     * XFLOAT_DATA (Vline_height_factor));
> +		      it->ascent = enlarged_height - it->descent;
> +		    }
>  		}
>  	    }
>  
> @@ -30886,6 +30914,13 @@ gui_produce_glyphs (struct it *it)
>  		{
>  		  it->ascent = FONT_BASE (font) + boff;
>  		  it->descent = FONT_DESCENT (font) - boff;
> +		  if (face == face->ascii_face && it->voffset == 0
> +		      && FLOATP (Vline_height_factor))
> +		    {
> +		      int enlarged_height = ((it->ascent + it->descent)
> +					     * XFLOAT_DATA (Vline_height_factor));
> +		      it->ascent = enlarged_height - it->descent;
> +		    }
>  		}
>  	      it->phys_ascent = it->ascent;
>  	      it->phys_descent = it->descent;
> @@ -31243,6 +31278,24 @@ gui_produce_glyphs (struct it *it)
>  	  if (it->glyph_row
>  	      && (metrics.lbearing < 0 || metrics.rbearing > metrics.width))
>  	    it->glyph_row->contains_overlapping_glyphs_p = true;
> +	  if (it->voffset == 0 && FLOATP (Vline_height_factor))
> +	    {
> +	      Lisp_Object font_object = LGSTRING_FONT (gstring);
> +	      struct font *gstring_font = XFONT_OBJECT (font_object);
> +
> +	      /* This is for when the grapheme cluster displays some
> +		 ligature using ASCII font: if the height is smaller
> +		 than line-height-factor says, enlarge the ascent.  */
> +	      if (face == face->ascii_face
> +		  && face->ascii_face->font == gstring_font)
> +		{
> +		  int enlarged_height =
> +		    ((FONT_BASE (gstring_font) + FONT_DESCENT (gstring_font))
> +		     * XFLOAT_DATA (Vline_height_factor));
> +		  if (metrics.ascent + metrics.descent < enlarged_height)
> +		    metrics.ascent = enlarged_height - metrics.descent;
> +		}
> +	    }
>  	  it->ascent = it->phys_ascent = metrics.ascent;
>  	  it->descent = it->phys_descent = metrics.descent;
>  	}
> @@ -35581,6 +35634,16 @@ syms_of_xdisp (void)
>  mini-window frame's default font's height.  */);
>    Vmax_mini_window_height = make_float (0.25);
>  
> +  DEFVAR_LISP ("line-height-factor", Vline_height_factor,
> +    doc: /* Factor for enlarging the height of lines that use the default font.
> +The value should be a float number greater than 1.  It determines how
> +much will Emacs enlarge the height of a screen line that shows only
> +characters displayed with the default face's font for ASCII characters.
> +This is to avoid differences in height between lines that use the
> +ASCII font and those which use non-ASCII (for example, Chinese)
> +font, which is typically higher than the ASCII one.  */);
> +  Vline_height_factor = Qnil;
> +
>    DEFVAR_LISP ("resize-mini-windows", Vresize_mini_windows,
>      doc: /* How to resize mini-windows (the minibuffer and the echo area).
>  A value of nil means don't automatically resize mini-windows.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Feng Shu]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 16 Nov 2021 18:45:16 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: tumashu@163.com, 51821@debbugs.gnu.org
>> 
>> > From: Lars Ingebrigtsen <larsi@gnus.org>
>> > Cc: tumashu@163.com,  51821@debbugs.gnu.org
>> > Date: Tue, 16 Nov 2021 16:20:52 +0100
>> > 
>> > > That shouldn't happen, normally.  Emacs selects fonts of the same size
>> > > for a face.
>> > 
>> > No, not really.  Here's a trivial example:
>> > 
>> > 
>> > Note how the lines with jidanni are taller than the rest.
>> 
>> OK, let me see what can be done about that.
>
> Please try the patch below.  I have a very limited number of cases
> with which I can test it, so I think users of CJK scripts should say
> what they think.  Basically, set the new variable line-height-factor
> to something like 1.2 (more if you enlarge the non-ASCII font to make
> double-width characters take close to 2 columns), and see if you get
> the desired effect.
>
> If this is what people want, I will install it and document it.
>

I think the below patch has problem, maybe it relate to font
baseline, I do not know, please see attachement.


[-- Attachment #2: test-2021-11-19_09.50.06.mkv --]
[-- Type: video/x-matroska, Size: 1227807 bytes --]

[-- Attachment #3: Type: text/plain, Size: 6098 bytes --]





> diff --git a/src/window.c b/src/window.c
> index e801ff8..a368b6d 100644
> --- a/src/window.c
> +++ b/src/window.c
> @@ -5246,7 +5246,10 @@ grow_mini_window (struct window *w, int delta)
>  {
>    struct frame *f = XFRAME (w->frame);
>    int old_height = window_body_height (w, true);
> -  int min_height = FRAME_LINE_HEIGHT (f);
> +  int min_height =
> +    FLOATP (Vline_height_factor)
> +    ? FRAME_LINE_HEIGHT (f) * XFLOAT_DATA (Vline_height_factor)
> +    : FRAME_LINE_HEIGHT (f);
>  
>    eassert (MINI_WINDOW_P (w));
>  
> @@ -5279,7 +5282,11 @@ grow_mini_window (struct window *w, int delta)
>  shrink_mini_window (struct window *w)
>  {
>    struct frame *f = XFRAME (w->frame);
> -  int delta = window_body_height (w, true) - FRAME_LINE_HEIGHT (f);
> +  int min_line_height =
> +    FLOATP (Vline_height_factor)
> +    ? FRAME_LINE_HEIGHT (f) * XFLOAT_DATA (Vline_height_factor)
> +    : FRAME_LINE_HEIGHT (f);
> +  int delta = window_body_height (w, true) - min_line_height;
>  
>    eassert (MINI_WINDOW_P (w));
>  
> diff --git a/src/xdisp.c b/src/xdisp.c
> index ef49297..d1f4043 100644
> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -22073,6 +22073,18 @@ append_space_for_newline (struct it *it, bool default_face_p)
>  		  it->descent = it->override_descent;
>  		  boff = it->override_boff;
>  		}
> +	      else
> +		{
> +		  /* Enlarge the ascent to make the row higher by
> +		     line-height-factor if needed.  */
> +		  if (face == face->ascii_face && it->voffset == 0
> +		      && FLOATP (Vline_height_factor))
> +		    {
> +		      int enlarged_height = ((it->ascent + it->descent)
> +					     * XFLOAT_DATA (Vline_height_factor));
> +		      it->ascent = enlarged_height - it->descent;
> +		    }
> +		}
>  	      if (EQ (height, Qt))
>  		extra_line_spacing = 0;
>  	      else
> @@ -30587,9 +30599,9 @@ gui_produce_glyphs (struct it *it)
>  	  /* When no suitable font is found, display this character by
>  	     the method specified in the first extra slot of
>  	     Vglyphless_char_display.  */
> -	      Lisp_Object acronym = lookup_glyphless_char_display (-1, it);
> +	  Lisp_Object acronym = lookup_glyphless_char_display (-1, it);
>  
> -	      eassert (it->what == IT_GLYPHLESS);
> +	  eassert (it->what == IT_GLYPHLESS);
>  	  produce_glyphless_glyph (it, true,
>  				   STRINGP (acronym) ? acronym : Qnil);
>  	  goto done;
> @@ -30613,6 +30625,15 @@ gui_produce_glyphs (struct it *it)
>   	    {
>   	      it->ascent = FONT_BASE (font) + boff;
>   	      it->descent = FONT_DESCENT (font) - boff;
> +	      /* If this glyph uses the ASCII face, enlarge the ascent
> +		 to make the row higher by line-height-factor.  */
> +	      if (face == face->ascii_face && it->voffset == 0
> +		  && FLOATP (Vline_height_factor))
> +		{
> +		  int enlarged_height = ((it->ascent + it->descent)
> +					 * XFLOAT_DATA (Vline_height_factor));
> +		  it->ascent = enlarged_height - it->descent;
> +		}
>   	    }
>  
>  	  if (get_char_glyph_code (it->char_to_display, font, &char2b))
> @@ -30763,6 +30784,13 @@ gui_produce_glyphs (struct it *it)
>  		{
>  		  it->ascent = FONT_BASE (font) + boff;
>  		  it->descent = FONT_DESCENT (font) - boff;
> +		  if (face == face->ascii_face && it->voffset == 0
> +		      && FLOATP (Vline_height_factor))
> +		    {
> +		      int enlarged_height = ((it->ascent + it->descent)
> +					     * XFLOAT_DATA (Vline_height_factor));
> +		      it->ascent = enlarged_height - it->descent;
> +		    }
>  		}
>  	    }
>  
> @@ -30886,6 +30914,13 @@ gui_produce_glyphs (struct it *it)
>  		{
>  		  it->ascent = FONT_BASE (font) + boff;
>  		  it->descent = FONT_DESCENT (font) - boff;
> +		  if (face == face->ascii_face && it->voffset == 0
> +		      && FLOATP (Vline_height_factor))
> +		    {
> +		      int enlarged_height = ((it->ascent + it->descent)
> +					     * XFLOAT_DATA (Vline_height_factor));
> +		      it->ascent = enlarged_height - it->descent;
> +		    }
>  		}
>  	      it->phys_ascent = it->ascent;
>  	      it->phys_descent = it->descent;
> @@ -31243,6 +31278,24 @@ gui_produce_glyphs (struct it *it)
>  	  if (it->glyph_row
>  	      && (metrics.lbearing < 0 || metrics.rbearing > metrics.width))
>  	    it->glyph_row->contains_overlapping_glyphs_p = true;
> +	  if (it->voffset == 0 && FLOATP (Vline_height_factor))
> +	    {
> +	      Lisp_Object font_object = LGSTRING_FONT (gstring);
> +	      struct font *gstring_font = XFONT_OBJECT (font_object);
> +
> +	      /* This is for when the grapheme cluster displays some
> +		 ligature using ASCII font: if the height is smaller
> +		 than line-height-factor says, enlarge the ascent.  */
> +	      if (face == face->ascii_face
> +		  && face->ascii_face->font == gstring_font)
> +		{
> +		  int enlarged_height =
> +		    ((FONT_BASE (gstring_font) + FONT_DESCENT (gstring_font))
> +		     * XFLOAT_DATA (Vline_height_factor));
> +		  if (metrics.ascent + metrics.descent < enlarged_height)
> +		    metrics.ascent = enlarged_height - metrics.descent;
> +		}
> +	    }
>  	  it->ascent = it->phys_ascent = metrics.ascent;
>  	  it->descent = it->phys_descent = metrics.descent;
>  	}
> @@ -35581,6 +35634,16 @@ syms_of_xdisp (void)
>  mini-window frame's default font's height.  */);
>    Vmax_mini_window_height = make_float (0.25);
>  
> +  DEFVAR_LISP ("line-height-factor", Vline_height_factor,
> +    doc: /* Factor for enlarging the height of lines that use the default font.
> +The value should be a float number greater than 1.  It determines how
> +much will Emacs enlarge the height of a screen line that shows only
> +characters displayed with the default face's font for ASCII characters.
> +This is to avoid differences in height between lines that use the
> +ASCII font and those which use non-ASCII (for example, Chinese)
> +font, which is typically higher than the ASCII one.  */);
> +  Vline_height_factor = Qnil;
> +
>    DEFVAR_LISP ("resize-mini-windows", Vresize_mini_windows,
>      doc: /* How to resize mini-windows (the minibuffer and the echo area).
>  A value of nil means don't automatically resize mini-windows.

-- 

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: tumashu@163.com,  larsi@gnus.org,  51821@debbugs.gnu.org
> Date: Fri, 19 Nov 2021 08:26:57 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Please try the patch below.  I have a very limited number of cases
> > with which I can test it, so I think users of CJK scripts should say
> > what they think.  Basically, set the new variable line-height-factor
> > to something like 1.2 (more if you enlarge the non-ASCII font to make
> > double-width characters take close to 2 columns), and see if you get
> > the desired effect.
> 
> Thanks, it seems to work well for what it's intended to.

Thanks for testing.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: luangruo@yahoo.com,  larsi@gnus.org,  51821@debbugs.gnu.org
> Date: Fri, 19 Nov 2021 09:57:25 +0800
> 
> I think the below patch has problem, maybe it relate to font
> baseline, I do not know, please see attachement.

Sorry, I cannot watch videos in that format.  What exactly seems to be
the problem with the results of the patch?  What did you try, exactly,
to test it, and what did you expect to happen instead of what actually
happened?

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> +  DEFVAR_LISP ("line-height-factor", Vline_height_factor,
> +    doc: /* Factor for enlarging the height of lines that use the default font.
> +The value should be a float number greater than 1.  It determines how
> +much will Emacs enlarge the height of a screen line that shows only
> +characters displayed with the default face's font for ASCII characters.
> +This is to avoid differences in height between lines that use the
> +ASCII font and those which use non-ASCII (for example, Chinese)
> +font, which is typically higher than the ASCII one.  */);

Is tying this to the default font the best solution, though?  Emacs (by
default) uses at least two fonts -- one monospaced and one that's
proportional, and this will only fix the first issue.

So I think the original idea (adding a line-height parameter/variable)
would fix this issue in a more general way.

Testing the patch, it also affects the height of faces with :height in
them, meaning that separator lines get much taller than they should be.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Sorry, I cannot watch videos in that format.  What exactly seems to be
> the problem with the results of the patch?  What did you try, exactly,
> to test it, and what did you expect to happen instead of what actually
> happened?

I think he expects the text in the smaller font to be "centered"
vertically, instead of sharing the same baseline as the Chinese font,
but I'm not sure.

Thanks.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[tumashu]

[-- Attachment #1.1: Type: text/plain, Size: 891 bytes --]




I just test like:

1. (setq line-height-factor 1.5)
2. M-x
3. yank "你好"
4. See minibuffer's height change or not.




maybe the height should split two parts, ascent and decent:

   real-ascent = ascent * line-height-factor
   real-decent = decent * line-height-factor



The patch seem to not change decent.
















At 2021-11-19 15:08:58, "Eli Zaretskii" <eliz@gnu.org> wrote:
>> From: "Feng Shu" <tumashu@163.com>
>> Cc: luangruo@yahoo.com,  larsi@gnus.org,  51821@debbugs.gnu.org
>> Date: Fri, 19 Nov 2021 09:57:25 +0800
>> 
>> I think the below patch has problem, maybe it relate to font
>> baseline, I do not know, please see attachement.
>
>Sorry, I cannot watch videos in that format.  What exactly seems to be
>the problem with the results of the patch?  What did you try, exactly,
>to test it, and what did you expect to happen instead of what actually
>happened?
>
>

[-- Attachment #1.2: Type: text/html, Size: 1396 bytes --]

[-- Attachment #2: test-2021-11-19_09.50.06.gif --]
[-- Type: image/gif, Size: 13643 bytes --]

bug#51821: Re: bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[tumashu]

At 2021-11-19 15:18:16, "Po Lu" <luangruo@yahoo.com> wrote:
>Eli Zaretskii <eliz@gnu.org> writes:
>
>> Sorry, I cannot watch videos in that format.  What exactly seems to be
>> the problem with the results of the patch?  What did you try, exactly,
>> to test it, and what did you expect to happen instead of what actually
>> happened?
>
>I think he expects the text in the smaller font to be "centered"
>vertically, instead of sharing the same baseline as the Chinese font,
>but I'm not sure. 

I do not know more about font technology, I just want to:

when I set a proper line-height-factor, and M-x, 
minibuffer's height can not change again after I paste Chinese.



>
>Thanks.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tumashu@163.com,  luangruo@yahoo.com,  51821@debbugs.gnu.org
> Date: Fri, 19 Nov 2021 08:12:30 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > +  DEFVAR_LISP ("line-height-factor", Vline_height_factor,
> > +    doc: /* Factor for enlarging the height of lines that use the default font.
> > +The value should be a float number greater than 1.  It determines how
> > +much will Emacs enlarge the height of a screen line that shows only
> > +characters displayed with the default face's font for ASCII characters.
> > +This is to avoid differences in height between lines that use the
> > +ASCII font and those which use non-ASCII (for example, Chinese)
> > +font, which is typically higher than the ASCII one.  */);
> 
> Is tying this to the default font the best solution, though?  Emacs (by
> default) uses at least two fonts -- one monospaced and one that's
> proportional, and this will only fix the first issue.

No, it should fix both.  Did you try that?  If you did and it didn't
work, can you show a recipe from "emacs -Q" so I could investigate?

The "default font" part above is an over-simplification: it is hard to
say something accurate enough in a single short sentence.  I did try
to explain it more in the rest of the doc string: this actually
affects any font which some face uses for ASCII characters.

> Testing the patch, it also affects the height of faces with :height in
> them, meaning that separator lines get much taller than they should be.

As I told you, it is currently impossible to single out such faces.
Also, I don't think we should necessarily exempt _any_ face that
specifies :height, because if that face is used to display with mixed
fonts, it will again have the same problem when both CJK fonts and
non-CJK fonts are mixed.  The separator lines are thus a very special
case, and if we want to solve that, we need a more focused solution.
For example, we could not stretch the height if the face's height is
below some threshold, on the assumption that such small fonts will
never used to display human-readable text.

But first I want to hear that CJK users are happy with this, and it
for now sounds like they aren't :-(

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: "Feng Shu" <tumashu@163.com>,  larsi@gnus.org,  51821@debbugs.gnu.org
> Date: Fri, 19 Nov 2021 15:18:16 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Sorry, I cannot watch videos in that format.  What exactly seems to be
> > the problem with the results of the patch?  What did you try, exactly,
> > to test it, and what did you expect to happen instead of what actually
> > happened?
> 
> I think he expects the text in the smaller font to be "centered"
> vertically, instead of sharing the same baseline as the Chinese font,
> but I'm not sure.

Really?  That can be done, but won't it look ugly on display?  Do
other GUI applications do that with mixed CJK and non-CJK fonts?

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> Date: Fri, 19 Nov 2021 15:26:21 +0800 (CST)
> From: tumashu  <tumashu@163.com>
> Cc: "Po Lu" <luangruo@yahoo.com>, "Lars Ingebrigtsen" <larsi@gnus.org>, 
> 	51821@debbugs.gnu.org
> 
> 1. (setq line-height-factor 1.5)
> 2. M-x
> 3. yank "你好"
> 4. See minibuffer's height change or not.

Does it change just once, or does it keep changing after that?

If it changes just once, it's not a significant problem, since the
setting of line-height-factor is normally expected to be in the init
file, and so you will not see this one-time change.

> maybe the height should split two parts, ascent and decent: 
> 
>    real-ascent = ascent * line-height-factor
>    real-decent = decent * line-height-factor
> 
> The patch seem to not change decent.

Why do you want to change the descent?

Anyway, if we change the descent, the baseline of ASCII characters
will be higher, which I think will look ugly on display.  Are you
familiar with any other application which does that, i.e. displays
different scripts with different baseline?

You show an image of the mode line, but don't tell what is the problem
with it.  Did you try displaying Chinese characters there?  Or what
else is the problem with it?

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> Date: Fri, 19 Nov 2021 15:31:16 +0800 (CST)
> From: tumashu  <tumashu@163.com>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, "Lars Ingebrigtsen" <larsi@gnus.org>, 
> 	"51821@debbugs.gnu.org" <51821@debbugs.gnu.org>
> 
> I do not know more about font technology, I just want to:
> 
> when I set a proper line-height-factor, and M-x, 
> minibuffer's height can not change again after I paste Chinese.

That is what's supposed to happen.  If it doesn't happen, please
describe the recipe exactly.

And the value of line-height-factor is supposed to be tuned to the
fonts you use, so if with 1.5 you see a change in the height, try
making the value larger until it doesn't change.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[tumashu]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

















At 2021-11-19 16:28:23, "Eli Zaretskii" <eliz@gnu.org> wrote:
>> Date: Fri, 19 Nov 2021 15:31:16 +0800 (CST)
>> From: tumashu  <tumashu@163.com>
>> Cc: "Eli Zaretskii" <eliz@gnu.org>, "Lars Ingebrigtsen" <larsi@gnus.org>, 
>> 	"51821@debbugs.gnu.org" <51821@debbugs.gnu.org>
>> 
>> I do not know more about font technology, I just want to:
>> 
>> when I set a proper line-height-factor, and M-x, 
>> minibuffer's height can not change again after I paste Chinese.
>
>That is what's supposed to happen.  If it doesn't happen, please
>describe the recipe exactly.

I have attache a gif motion picture, it showd that minibuffer's height change again after
I paste "你好"

Every time when I M-x and paste.

>
>And the value of line-height-factor is supposed to be tuned to the
>fonts you use, so if with 1.5 you see a change in the height, try
>making the value larger until it doesn't change.

When I set it to 2.0,  the problem exist too.

>
>

[-- Attachment #2: test-2021-11-19_09.50.06.gif --]
[-- Type: image/gif, Size: 13643 bytes --]

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[tumashu]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

















At 2021-11-19 16:25:05, "Eli Zaretskii" <eliz@gnu.org> wrote:
>> Date: Fri, 19 Nov 2021 15:26:21 +0800 (CST)
>> From: tumashu  <tumashu@163.com>
>> Cc: "Po Lu" <luangruo@yahoo.com>, "Lars Ingebrigtsen" <larsi@gnus.org>, 
>> 	51821@debbugs.gnu.org
>> 
>> 1. (setq line-height-factor 1.5)
>> 2. M-x
>> 3. yank "你好"
>> 4. See minibuffer's height change or not.
>
>Does it change just once, or does it keep changing after that?

every time when I M-x and insert Chinese char.

>
>If it changes just once, it's not a significant problem, since the
>setting of line-height-factor is normally expected to be in the init
>file, and so you will not see this one-time change.
>
>> maybe the height should split two parts, ascent and decent: 
>> 
>>    real-ascent = ascent * line-height-factor
>>    real-decent = decent * line-height-factor
>> 
>> The patch seem to not change decent.
>
>Why do you want to change the descent?

Ascii font's baseline shoud align to Chinese font's baseline, I think.

any other way to achive this, if we do not change descent? I do not know.
>
>Anyway, if we change the descent, the baseline of ASCII characters
>will be higher, which I think will look ugly on display.  Are you
>familiar with any other application which does that, i.e. displays
>different scripts with different baseline?

See attach baseline.png,  Chinese and Ascii align baseline in most situation.

>
>You show an image of the mode line, but don't tell what is the problem
>with it.  Did you try displaying Chinese characters there?  Or what
>else is the problem with it?
>
>

[-- Attachment #2: baseline.png --]
[-- Type: image/png, Size: 65077 bytes --]

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[tumashu]

>> maybe the height should split two parts, ascent and decent: 
>> 
>>    real-ascent = ascent * line-height-factor
>>    real-decent = decent * line-height-factor
>> 
>> The patch seem to not change decent.
>
>Why do you want to change the descent?
>

when we set fonts and let  1 Chinese char width = 2 * ASCII char width,
ASCII font size may different from Chinese font size, so maybe they are have different baseline.

so how to align to baseline, I do not know.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think he expects the text in the smaller font to be "centered"
>> vertically, instead of sharing the same baseline as the Chinese font,
>> but I'm not sure.

> Really?  That can be done, but won't it look ugly on display?

IMO yes, but other people might have differing opinions.  Would it hurt
to make this an option?

> Do other GUI applications do that with mixed CJK and non-CJK fonts?

I found out earlier that the other applications simply scale the
overlarge glyphs to fit some predefined height.  In Chromium, it's
defined in CSS, but in other programs it's probably the height of the
ASCII font, or whichever font the user has configured.  (Other programs
generally don't provide the ability to customize the fontset, only a
single font.)

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> Date: Fri, 19 Nov 2021 17:09:31 +0800 (CST)
> From: tumashu  <tumashu@163.com>
> Cc: "Po Lu" <luangruo@yahoo.com>, "Lars Ingebrigtsen" <larsi@gnus.org>, 
> 	"51821@debbugs.gnu.org" <51821@debbugs.gnu.org>
> 
> >Why do you want to change the descent?
> >
> 
> when we set fonts and let  1 Chinese char width = 2 * ASCII char width,
> ASCII font size may different from Chinese font size, so maybe they are have different baseline.
> 
> so how to align to baseline, I do not know.

The only way I know of to have the baseline aligned is not to change
the descent.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: tumashu@163.com,  larsi@gnus.org,  51821@debbugs.gnu.org
> Date: Fri, 19 Nov 2021 17:33:18 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I think he expects the text in the smaller font to be "centered"
> >> vertically, instead of sharing the same baseline as the Chinese font,
> >> but I'm not sure.
> 
> > Really?  That can be done, but won't it look ugly on display?
> 
> IMO yes, but other people might have differing opinions.  Would it hurt
> to make this an option?

I'd rather not introduce one more option to control the line height
unless it's really needed.  The code there is already a "maze of
twisted passages all alike", quite hard to understand and modify, so
adding one more option could easily break something.

For now, it does sound like Feng Shu wants the baseline aligned, so
such an option is not required yet.

> > Do other GUI applications do that with mixed CJK and non-CJK fonts?
> 
> I found out earlier that the other applications simply scale the
> overlarge glyphs to fit some predefined height.

Emacs doesn't scale the font glyphs, AFAIK, primarily because that
won't work with bitmapped fonts, which we still support and which some
users still use (I remember recent enough bug reports due to some
change that broke bitmapped fonts).  We let the font backend do the
scaling, when we request a font of certain size, and the result is
what you see now.

But if you or someone else know how to scale font glyphs on the fly,
please show the code.  The main difficulty her, as I see it, is to
decide to which size to scale, since each character can have a glyph
with different metrics.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> I'd rather not introduce one more option to control the line height
> unless it's really needed.  The code there is already a "maze of
> twisted passages all alike", quite hard to understand and modify, so
> adding one more option could easily break something.

I understand, thanks.  But I don't understand what other problem tumashu
has, because I can't see anything specific in the recording he sent.

> For now, it does sound like Feng Shu wants the baseline aligned, so
> such an option is not required yet.

That's good to hear.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 16 Nov 2021 18:45:16 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: tumashu@163.com, 51821@debbugs.gnu.org
>> 
>> > From: Lars Ingebrigtsen <larsi@gnus.org>
>> > Cc: tumashu@163.com,  51821@debbugs.gnu.org
>> > Date: Tue, 16 Nov 2021 16:20:52 +0100
>> > 
>> > > That shouldn't happen, normally.  Emacs selects fonts of the same size
>> > > for a face.
>> > 
>> > No, not really.  Here's a trivial example:
>> > 
>> > 
>> > Note how the lines with jidanni are taller than the rest.
>> 
>> OK, let me see what can be done about that.
>
> Please try the patch below.  I have a very limited number of cases
> with which I can test it, so I think users of CJK scripts should say
> what they think.  Basically, set the new variable line-height-factor
> to something like 1.2 (more if you enlarge the non-ASCII font to make
> double-width characters take close to 2 columns), and see if you get
> the desired effect.
>
> If this is what people want, I will install it and document it.

I have tested with a hacked version of below patch, I think we need two
factors: ascent-factor and descent-factor.

    ascent = ascent * ascent-factor
    descent = descent * descent-factor

When I set ascent = 1.1 and descent = 1.3, 
minibuffer's height do not change when I M-x and paste Chinese.

maybe line-height-factor should be a cons, for example: (1.1 . 1.3)

>
> diff --git a/src/window.c b/src/window.c
> index e801ff8..a368b6d 100644
> --- a/src/window.c
> +++ b/src/window.c
> @@ -5246,7 +5246,10 @@ grow_mini_window (struct window *w, int delta)
>  {
>    struct frame *f = XFRAME (w->frame);
>    int old_height = window_body_height (w, true);
> -  int min_height = FRAME_LINE_HEIGHT (f);
> +  int min_height =
> +    FLOATP (Vline_height_factor)
> +    ? FRAME_LINE_HEIGHT (f) * XFLOAT_DATA (Vline_height_factor)
> +    : FRAME_LINE_HEIGHT (f);
>  
>    eassert (MINI_WINDOW_P (w));
>  
> @@ -5279,7 +5282,11 @@ grow_mini_window (struct window *w, int delta)
>  shrink_mini_window (struct window *w)
>  {
>    struct frame *f = XFRAME (w->frame);
> -  int delta = window_body_height (w, true) - FRAME_LINE_HEIGHT (f);
> +  int min_line_height =
> +    FLOATP (Vline_height_factor)
> +    ? FRAME_LINE_HEIGHT (f) * XFLOAT_DATA (Vline_height_factor)
> +    : FRAME_LINE_HEIGHT (f);
> +  int delta = window_body_height (w, true) - min_line_height;
>  
>    eassert (MINI_WINDOW_P (w));
>  
> diff --git a/src/xdisp.c b/src/xdisp.c
> index ef49297..d1f4043 100644
> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -22073,6 +22073,18 @@ append_space_for_newline (struct it *it, bool default_face_p)
>  		  it->descent = it->override_descent;
>  		  boff = it->override_boff;
>  		}
> +	      else
> +		{
> +		  /* Enlarge the ascent to make the row higher by
> +		     line-height-factor if needed.  */
> +		  if (face == face->ascii_face && it->voffset == 0
> +		      && FLOATP (Vline_height_factor))
> +		    {
> +		      int enlarged_height = ((it->ascent + it->descent)
> +					     * XFLOAT_DATA (Vline_height_factor));
> +		      it->ascent = enlarged_height - it->descent;
> +		    }
> +		}
>  	      if (EQ (height, Qt))
>  		extra_line_spacing = 0;
>  	      else
> @@ -30587,9 +30599,9 @@ gui_produce_glyphs (struct it *it)
>  	  /* When no suitable font is found, display this character by
>  	     the method specified in the first extra slot of
>  	     Vglyphless_char_display.  */
> -	      Lisp_Object acronym = lookup_glyphless_char_display (-1, it);
> +	  Lisp_Object acronym = lookup_glyphless_char_display (-1, it);
>  
> -	      eassert (it->what == IT_GLYPHLESS);
> +	  eassert (it->what == IT_GLYPHLESS);
>  	  produce_glyphless_glyph (it, true,
>  				   STRINGP (acronym) ? acronym : Qnil);
>  	  goto done;
> @@ -30613,6 +30625,15 @@ gui_produce_glyphs (struct it *it)
>   	    {
>   	      it->ascent = FONT_BASE (font) + boff;
>   	      it->descent = FONT_DESCENT (font) - boff;
> +	      /* If this glyph uses the ASCII face, enlarge the ascent
> +		 to make the row higher by line-height-factor.  */
> +	      if (face == face->ascii_face && it->voffset == 0
> +		  && FLOATP (Vline_height_factor))
> +		{
> +		  int enlarged_height = ((it->ascent + it->descent)
> +					 * XFLOAT_DATA (Vline_height_factor));
> +		  it->ascent = enlarged_height - it->descent;
> +		}
>   	    }
>  
>  	  if (get_char_glyph_code (it->char_to_display, font, &char2b))
> @@ -30763,6 +30784,13 @@ gui_produce_glyphs (struct it *it)
>  		{
>  		  it->ascent = FONT_BASE (font) + boff;
>  		  it->descent = FONT_DESCENT (font) - boff;
> +		  if (face == face->ascii_face && it->voffset == 0
> +		      && FLOATP (Vline_height_factor))
> +		    {
> +		      int enlarged_height = ((it->ascent + it->descent)
> +					     * XFLOAT_DATA (Vline_height_factor));
> +		      it->ascent = enlarged_height - it->descent;
> +		    }
>  		}
>  	    }
>  
> @@ -30886,6 +30914,13 @@ gui_produce_glyphs (struct it *it)
>  		{
>  		  it->ascent = FONT_BASE (font) + boff;
>  		  it->descent = FONT_DESCENT (font) - boff;
> +		  if (face == face->ascii_face && it->voffset == 0
> +		      && FLOATP (Vline_height_factor))
> +		    {
> +		      int enlarged_height = ((it->ascent + it->descent)
> +					     * XFLOAT_DATA (Vline_height_factor));
> +		      it->ascent = enlarged_height - it->descent;
> +		    }
>  		}
>  	      it->phys_ascent = it->ascent;
>  	      it->phys_descent = it->descent;
> @@ -31243,6 +31278,24 @@ gui_produce_glyphs (struct it *it)
>  	  if (it->glyph_row
>  	      && (metrics.lbearing < 0 || metrics.rbearing > metrics.width))
>  	    it->glyph_row->contains_overlapping_glyphs_p = true;
> +	  if (it->voffset == 0 && FLOATP (Vline_height_factor))
> +	    {
> +	      Lisp_Object font_object = LGSTRING_FONT (gstring);
> +	      struct font *gstring_font = XFONT_OBJECT (font_object);
> +
> +	      /* This is for when the grapheme cluster displays some
> +		 ligature using ASCII font: if the height is smaller
> +		 than line-height-factor says, enlarge the ascent.  */
> +	      if (face == face->ascii_face
> +		  && face->ascii_face->font == gstring_font)
> +		{
> +		  int enlarged_height =
> +		    ((FONT_BASE (gstring_font) + FONT_DESCENT (gstring_font))
> +		     * XFLOAT_DATA (Vline_height_factor));
> +		  if (metrics.ascent + metrics.descent < enlarged_height)
> +		    metrics.ascent = enlarged_height - metrics.descent;
> +		}
> +	    }
>  	  it->ascent = it->phys_ascent = metrics.ascent;
>  	  it->descent = it->phys_descent = metrics.descent;
>  	}
> @@ -35581,6 +35634,16 @@ syms_of_xdisp (void)
>  mini-window frame's default font's height.  */);
>    Vmax_mini_window_height = make_float (0.25);
>  
> +  DEFVAR_LISP ("line-height-factor", Vline_height_factor,
> +    doc: /* Factor for enlarging the height of lines that use the default font.
> +The value should be a float number greater than 1.  It determines how
> +much will Emacs enlarge the height of a screen line that shows only
> +characters displayed with the default face's font for ASCII characters.
> +This is to avoid differences in height between lines that use the
> +ASCII font and those which use non-ASCII (for example, Chinese)
> +font, which is typically higher than the ASCII one.  */);
> +  Vline_height_factor = Qnil;
> +
>    DEFVAR_LISP ("resize-mini-windows", Vresize_mini_windows,
>      doc: /* How to resize mini-windows (the minibuffer and the echo area).
>  A value of nil means don't automatically resize mini-windows.

-- 

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Sun, 14 Nov 2021 02:23:46 +0100
>> Cc: 51821@debbugs.gnu.org
>> 
>> "Feng Shu" <tumashu@163.com> writes:
>> 
>> > Maybe we should add a variable or frame parameter: line-height
>> 
>> Sounds good to me.  Perhaps call it min{imum,}-line-height, though.
>
> IMO it should be line-height, for similarity with line-spacing.

Hi Eli and Lars

yestaday, I have tested with hack version of your patch, I think
line-height or line-height-factor is not a proper way to solve my core
problem.

   My core problem is how to let tab/mode/header-line and minibuffer's
   height do not change depend Chinese exist or not.

line-height-factor can let their height do not change, but the problem
is that the result looks very ugly, for line-space very large, It will
be painful in daily use.


so I think the good approach maybe is providing a simple way, by which
we can easy let no-ascii font use small height if a face is not used in
table like environment.

In my opinion "1 Chinese char width = 2 * ASCII char width" is *only*
useful in table like environment. let Chinese char's height <= ASCII
char's height will work well in other situation, and have no
tab/mode/header-line height change problem too.



-- 

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  51821@debbugs.gnu.org
> Date: Sat, 20 Nov 2021 07:03:18 +0800
> 
> yestaday, I have tested with hack version of your patch, I think
> line-height or line-height-factor is not a proper way to solve my core
> problem.
> 
>    My core problem is how to let tab/mode/header-line and minibuffer's
>    height do not change depend Chinese exist or not.

That's a different problem from that Lars wanted to solve, AFAIU.

> line-height-factor can let their height do not change, but the problem
> is that the result looks very ugly, for line-space very large, It will
> be painful in daily use.

I agree it is not very pretty, but I don't see how such a feature
could do much better.

> so I think the good approach maybe is providing a simple way, by which
> we can easy let no-ascii font use small height if a face is not used in
> table like environment.

That's no longer a display issue, I think.  And I don't really
understand how we could implement that, since faces are oblivious to
the context in which they are used.

And what do you mean by "table like environment"? do you mean
tabulated-list-mode and its descendants, or do you mean Org tables, or
do you mean just simple text display that emulates tables by aligning
text on column boundaries, like, for example, in Gnus summary buffers?

And finally, what do you mean by "no-ascii font use small height" --
how will Emacs ensure such smaller height of these fonts?

> In my opinion "1 Chinese char width = 2 * ASCII char width" is *only*
> useful in table like environment. let Chinese char's height <= ASCII
> char's height will work well in other situation, and have no
> tab/mode/header-line height change problem too.

Until now, your main concern was that the echo-area height changes
depending on whether it does or doesn't show Chinese characters.  Are
you now saying that concern is no longer important?  If so, why do we
need to do anything about the height of the Chinese font used by Emacs
in text that mixes Chinese and ASCII characters?

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Feng Shu" <tumashu@163.com>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  51821@debbugs.gnu.org
>> Date: Sat, 20 Nov 2021 07:03:18 +0800
>> 
>> yestaday, I have tested with hack version of your patch, I think
>> line-height or line-height-factor is not a proper way to solve my core
>> problem.
>> 
>>    My core problem is how to let tab/mode/header-line and minibuffer's
>>    height do not change depend Chinese exist or not.
>
> That's a different problem from that Lars wanted to solve, AFAIU.

Really? wait to good news :-)

>
>> line-height-factor can let their height do not change, but the problem
>> is that the result looks very ugly, for line-space very large, It will
>> be painful in daily use.
>
> I agree it is not very pretty, but I don't see how such a feature
> could do much better.

:-)

>
>> so I think the good approach maybe is providing a simple way, by which
>> we can easy let no-ascii font use small height if a face is not used in
>> table like environment.
>
> That's no longer a display issue, I think.  And I don't really
> understand how we could implement that, since faces are oblivious to
> the context in which they are used.

I do not know too, just a guess :-),  let face use a fontset? I do not know.

>
> And what do you mean by "table like environment"? do you mean
> tabulated-list-mode and its descendants, or do you mean Org tables, or

yes, include

> do you mean just simple text display that emulates tables by aligning
> text on column boundaries, like, for example, in Gnus summary buffers?

yes, include

>
> And finally, what do you mean by "no-ascii font use small height" --
> how will Emacs ensure such smaller height of these fonts?
>
>> In my opinion "1 Chinese char width = 2 * ASCII char width" is *only*
>> useful in table like environment. let Chinese char's height <= ASCII
>> char's height will work well in other situation, and have no
>> tab/mode/header-line height change problem too.
>
> Until now, your main concern was that the echo-area height changes
> depending on whether it does or doesn't show Chinese characters.  Are

Yes, it is my main concern.

> you now saying that concern is no longer important?  If so, why do we

No, I mean if Chinese font's height <= ASCII font height, it will no
this problem, so I think line height will no longer important at this
situation.

> need to do anything about the height of the Chinese font used by Emacs
> in text that mixes Chinese and ASCII characters?




-- 

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: "Feng Shu" <tumashu@163.com>
> Cc: larsi@gnus.org,  51821@debbugs.gnu.org
> Date: Sat, 20 Nov 2021 15:13:16 +0800
> 
> No, I mean if Chinese font's height <= ASCII font height, it will no
> this problem, so I think line height will no longer important at this
> situation.

But how to achieve this, except by asking the user to find a suitable
Chinese font and configure the fontset accordingly?  Once a font is
selected for a face to display a certain script, Emacs just uses that
font with whatever height it has.  We don't dynamically change the
font size during display (and not all fonts even can be resized).

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Feng Shu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Feng Shu" <tumashu@163.com>
>> Cc: larsi@gnus.org,  51821@debbugs.gnu.org
>> Date: Sat, 20 Nov 2021 15:13:16 +0800
>> 
>> No, I mean if Chinese font's height <= ASCII font height, it will no
>> this problem, so I think line height will no longer important at this
>> situation.
>
> But how to achieve this, except by asking the user to find a suitable
> Chinese font and configure the fontset accordingly?  Once a font is
> selected for a face to display a certain script, Emacs just uses that
> font with whatever height it has.  We don't dynamically change the
> font size during display (and not all fonts even can be resized).

I do not know :-)


-- 

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> No, it should fix both.  Did you try that?  If you did and it didn't
> work, can you show a recipe from "emacs -Q" so I could investigate?

No, I only tested in buffers with a monospaced font and then read the
doc string.

> The "default font" part above is an over-simplification: it is hard to
> say something accurate enough in a single short sentence.  I did try
> to explain it more in the rest of the doc string: this actually
> affects any font which some face uses for ASCII characters.

Perhaps "default font(s)" would help.

>> Testing the patch, it also affects the height of faces with :height in
>> them, meaning that separator lines get much taller than they should be.
>
> As I told you, it is currently impossible to single out such faces.

Right, but I think I said that it should be pretty easy to carry that
information in struct face if we want to go that way.

> Also, I don't think we should necessarily exempt _any_ face that
> specifies :height, because if that face is used to display with mixed
> fonts, it will again have the same problem when both CJK fonts and
> non-CJK fonts are mixed.

Hm...  Yeah, that's true.  For instance, in eww in <h1> we have :height
1.3, and we probably want the CJK/non-CJK font mixture to be handled the
same way as if there isn't a :height there.  OK, the :height thing
doesn't work.

> The separator lines are thus a very special
> case, and if we want to solve that, we need a more focused solution.
> For example, we could not stretch the height if the face's height is
> below some threshold, on the assumption that such small fonts will
> never used to display human-readable text.

Hm, yes, the separator lines are very special, and the :height thing is
more a hack than anything else.  Perhaps we should just introduce a new
spec, like :pixel-height that allows us to specify specifically how big
the separator line should be.

Hm.  Or not use faces at all for the separator lines?  I don't know how
that would look, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tumashu@163.com,  luangruo@yahoo.com,  51821@debbugs.gnu.org
> Date: Sat, 20 Nov 2021 09:26:19 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, it should fix both.  Did you try that?  If you did and it didn't
> > work, can you show a recipe from "emacs -Q" so I could investigate?
> 
> No, I only tested in buffers with a monospaced font and then read the
> doc string.
> 
> > The "default font" part above is an over-simplification: it is hard to
> > say something accurate enough in a single short sentence.  I did try
> > to explain it more in the rest of the doc string: this actually
> > affects any font which some face uses for ASCII characters.
> 
> Perhaps "default font(s)" would help.

For now, all of this seems like a moot point, since the "main
customer" doesn't seem to want this implementation anyway.

> > The separator lines are thus a very special
> > case, and if we want to solve that, we need a more focused solution.
> > For example, we could not stretch the height if the face's height is
> > below some threshold, on the assumption that such small fonts will
> > never used to display human-readable text.
> 
> Hm, yes, the separator lines are very special, and the :height thing is
> more a hack than anything else.  Perhaps we should just introduce a new
> spec, like :pixel-height that allows us to specify specifically how big
> the separator line should be.

Shouldn't it be enough to check that the face's height is less than 2
pixels, and if so, not to enlarge the height?

But again, this sounds like a moot point for now.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Shouldn't it be enough to check that the face's height is less than 2
> pixels, and if so, not to enlarge the height?

Perhaps, but I'm pretty sure that on this HiDPI screen, the separator
line height is about... four? pixels high.  And this is with :height
0.1, anything smaller than that gives me this error:

set-face-attribute: Face height does not produce a positive integer: 0.09

> But again, this sounds like a moot point for now.

Yup.  But perhaps it would make sense to allow for :pixel-height in any
case -- it'd be one less thing to worry about when figuring our options
when trying to get to a solution.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tumashu@163.com,  luangruo@yahoo.com,  51821@debbugs.gnu.org
> Date: Sat, 20 Nov 2021 09:51:39 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Shouldn't it be enough to check that the face's height is less than 2
> > pixels, and if so, not to enlarge the height?
> 
> Perhaps, but I'm pretty sure that on this HiDPI screen, the separator
> line height is about... four? pixels high.

Well, the value 2 above was just arbitrary; we could use 4 instead.

> Yup.  But perhaps it would make sense to allow for :pixel-height in any
> case -- it'd be one less thing to worry about when figuring our options
> when trying to get to a solution.

Not sure I understand what you mean by "allow foe :pixel-height" here.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Yup.  But perhaps it would make sense to allow for :pixel-height in any
>> case -- it'd be one less thing to worry about when figuring our options
>> when trying to get to a solution.
>
> Not sure I understand what you mean by "allow foe :pixel-height" here.

Allow saying:

(defface separator-line
  '((((type graphic) (background dark))
     :pixel-height 1 :background "#505050")


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tumashu@163.com,  luangruo@yahoo.com,  51821@debbugs.gnu.org
> Date: Sat, 20 Nov 2021 10:27:26 +0100
> 
> > Not sure I understand what you mean by "allow foe :pixel-height" here.
> 
> Allow saying:
> 
> (defface separator-line
>   '((((type graphic) (background dark))
>      :pixel-height 1 :background "#505050")

How is that different from :height?  It uses different units, but
that's not a problem for this use case, is it?

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Allow saying:
>> 
>> (defface separator-line
>>   '((((type graphic) (background dark))
>>      :pixel-height 1 :background "#505050")
>
> How is that different from :height?  It uses different units, but
> that's not a problem for this use case, is it?

It's a way to say "don't scale this, ever", which was a problem here,
wasn't it?  (And :height 0.1 doesn't give me a single pixel on this
display -- we have no way to express that currently.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tumashu@163.com,  luangruo@yahoo.com,  51821@debbugs.gnu.org
> Date: Sat, 20 Nov 2021 10:58:14 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Allow saying:
> >> 
> >> (defface separator-line
> >>   '((((type graphic) (background dark))
> >>      :pixel-height 1 :background "#505050")
> >
> > How is that different from :height?  It uses different units, but
> > that's not a problem for this use case, is it?
> 
> It's a way to say "don't scale this, ever", which was a problem here,
> wasn't it?  (And :height 0.1 doesn't give me a single pixel on this
> display -- we have no way to express that currently.)

No, float values are relative to the default face, which is not what
you want.  I meant ":height 1" or somesuch.  If that is not good
enough, the value of :height can be a function.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> No, float values are relative to the default face, which is not what
> you want.  I meant ":height 1" or somesuch.  If that is not good
> enough, the value of :height can be a function.

If we're going to be scaling stuff, it'd be nice if there was a setting
that was clearly non-scaleable.  An integer value to :height would be
possible, but pretty error-prone, so I'd rather introduce a new keyword.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tumashu@163.com,  luangruo@yahoo.com,  51821@debbugs.gnu.org
> Date: Sun, 21 Nov 2021 09:06:44 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, float values are relative to the default face, which is not what
> > you want.  I meant ":height 1" or somesuch.  If that is not good
> > enough, the value of :height can be a function.
> 
> If we're going to be scaling stuff, it'd be nice if there was a setting
> that was clearly non-scaleable.  An integer value to :height would be
> possible, but pretty error-prone

How is something like ":height 1" error-prone?

> so I'd rather introduce a new keyword.

Adding a new face attribute is not a 5-min job, so if we already have
something that can work, it is better to use it.  Especially if you
want to introduce an attribute that potentially conflicts with an
existing attribute.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> If we're going to be scaling stuff, it'd be nice if there was a setting
>> that was clearly non-scaleable.  An integer value to :height would be
>> possible, but pretty error-prone
>
> How is something like ":height 1" error-prone?

Because people aren't expecting ":height 1" and ":height 1.0" to have
such different semantics.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tumashu@163.com,  luangruo@yahoo.com,  51821@debbugs.gnu.org
> Date: Sun, 21 Nov 2021 09:21:25 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> If we're going to be scaling stuff, it'd be nice if there was a setting
> >> that was clearly non-scaleable.  An integer value to :height would be
> >> possible, but pretty error-prone
> >
> > How is something like ":height 1" error-prone?
> 
> Because people aren't expecting ":height 1" and ":height 1.0" to have
> such different semantics.

??? That ship has sailed long ago, in Emacs 21.  Float values and
integer values have different meanings in these face attributes (and
in other similar features, like line-height, the "space :height"
display spec, etc.).  Why is this suddenly a problem, and one that
requires a new face attribute at that?

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> ??? That ship has sailed long ago, in Emacs 21.  Float values and
> integer values have different meanings in these face attributes (and
> in other similar features, like line-height, the "space :height"
> display spec, etc.).  Why is this suddenly a problem, and one that
> requires a new face attribute at that?

I don't think we have to compound the error by extending this mis-design
to new areas, but I won't insist.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> ??? That ship has sailed long ago, in Emacs 21.  Float values and
>> integer values have different meanings in these face attributes (and
>> in other similar features, like line-height, the "space :height"
>> display spec, etc.).  Why is this suddenly a problem, and one that
>> requires a new face attribute at that?

> I don't think we have to compound the error by extending this mis-design
> to new areas, but I won't insist.

FWIW I don't find it a mis-design.  Floating point values very obviously
mean something different than an integer value, not only in Emacs, but
in most other real-world software.

Thanks.

bug#51821: 29.0.50; Suggest add variable or frame parameter: line-height

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tumashu@163.com,  luangruo@yahoo.com,  51821@debbugs.gnu.org
> Date: Sun, 21 Nov 2021 09:38:06 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > ??? That ship has sailed long ago, in Emacs 21.  Float values and
> > integer values have different meanings in these face attributes (and
> > in other similar features, like line-height, the "space :height"
> > display spec, etc.).  Why is this suddenly a problem, and one that
> > requires a new face attribute at that?
> 
> I don't think we have to compound the error by extending this mis-design
> to new areas, but I won't insist.

The question is, how many more Emacs Lisp programmers consider this
mis-design natural, like I do?

But I'm not objecting if you or someone else wants to add such an
attribute, I just warn that it probably won't be trivial.