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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Feng Shu" <tumashu <at> 163.com>
Cc: 51821 <at> debbugs.gnu.org
Subject: Re: bug#51821: 29.0.50; Suggest add variable or frame parameter:
 line-height
Date: Mon, 15 Nov 2021 14:38:08 +0200

> From: "Feng Shu" <tumashu <at> 163.com>
> Cc: 51821 <at> 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.

Previous Next

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