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

["Feng Shu" <tumashu@163.com>]

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 

--