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

Previous Next

Full log

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

From: "Feng Shu" <tumashu <at> 163.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51821 <at> debbugs.gnu.org
Subject: Re: bug#51821: 29.0.50; Suggest add variable or frame parameter:
 line-height
Date: Tue, 16 Nov 2021 11:51:16 +0800

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

>> 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

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 

-- 

Previous Next

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