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

From: "Feng Shu" <[email-masked]>
Date: Tue, 16 Nov 2021 11:51:16 +0800

Eli Zaretskii <[email-masked]> writes:

>> From: "Feng Shu" <[email-masked]>
>> Cc: [email-masked]
>> 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 

--