From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Tick Reduction Date: Sun, 21 Nov 2021 21:31:03 +0200 Message-ID: <83h7c5qpag.fsf@gnu.org> References: <87bl2hyzca.fsf@gnus.org> <8735nszpdv.fsf@gnus.org> <87sfvswrp8.fsf@gnus.org> <834k88woaj.fsf@gnu.org> <878rxkv980.fsf@gnus.org> <87sfvpmtl8.fsf@gnus.org> <83pmqtqvj5.fsf@gnu.org> <87bl2dmnfa.fsf@gnus.org> <83mtlxquh7.fsf@gnu.org> <877dd1mlsd.fsf@gnus.org> <83k0h1qss5.fsf@gnu.org> <8735npmkm5.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13767"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, stefankangas@gmail.com, dgutov@yandex.ru To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 21 20:33:30 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mosaf-0003Qp-Ul for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Nov 2021 20:33:30 +0100 Original-Received: from localhost ([::1]:52734 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mosae-0007n3-K3 for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Nov 2021 14:33:28 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55598) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mosYL-00065F-MJ for emacs-devel@gnu.org; Sun, 21 Nov 2021 14:31:06 -0500 Original-Received: from [2001:470:142:3::e] (port=60552 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mosYL-0004vB-Cx; Sun, 21 Nov 2021 14:31:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=KiL/BVukwaQcNowxBHpPCMwggInFh4pVgmr3Im1boZ4=; b=QNL45UvyW2le Xko1bEilsvJJaVVYciZqDyf3hasz66/lSksCySfnOGGruljF5ga/Xmr54ct5seoVr0hXuniYrlgAc qCp+eQ/8xx6A0GwbXnKDmwyQAeezlE7s1slV5uHsCazuVuflZmyuMojkSjcwsDAFuyDLSsg4ThUvN Eu8mgEf8EpxzUzFl9ywzA1K/7xvw36JNmzdME1aypSL0sRmln4VW7iXPOqViCGA1tBj25ku1xHY5U rEVEbawUz1ZSfj72OfCY//yS32XBLhez69oSysfL6Cm2+E0d87Kj3ZaQYCzI83IZU+f1X+97t2zb9 jbq6LnWc16KeS17O/lpJ3Q==; Original-Received: from [87.69.77.57] (port=1460 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mosYE-0007eR-5n; Sun, 21 Nov 2021 14:31:00 -0500 In-Reply-To: <8735npmkm5.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 21 Nov 2021 19:25:38 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:279875 Archived-At: > From: Lars Ingebrigtsen > Cc: dgutov@yandex.ru, stefankangas@gmail.com, emacs-devel@gnu.org > Date: Sun, 21 Nov 2021 19:25:38 +0100 > > Eli Zaretskii writes: > > > Sorry, I'm now confused. You say the width of "L" will not be changed > > and the width of digits doesn't need to be changed? Then why are we > > doing all this, if there will be no change? > > The column/line specs use spaces to fill out (I think it defaults to > three char positions for the L spec?), and it's really only these that > will be affected by the monospaciation (in that spec). > > > (And btw, displaying "L" normally while "1234" not normally is quite a > > lot more difficult than handling all characters the same, because the > > display code generally doesn't distinguish between characters. Unless > > you make "L" that "default character" whose advance width is used for > > all the other characters, that is. But if you do that, then what > > about "C" in the column number?) > > The L won't be displayed normally either, but like the numbers, the L > won't be affected, because it's also as wide or wider than the "normal > font width" (i.e., font->average_width). Beware: with proportional fonts, the value of font->average_width is sometimes surprising. > >> First line without monospacification, second line with: > > > > For the "U:---" part, each dash character is a separate field, so what > > are the benefits of using proportional fonts there? > > Because mixing fonts here makes things look weird. > > > For the line/column number, I don't see any significant difference, > > barely a pixel here and there. So I wonder what is this all about. > > With this font (as with most fonts), the displays of the line/column > numbers should be identical. (Except for the spaces.) I think we may be mis-communicating. Can you take an example of a full mode line and tell which part(s) of it will use proportional fonts "as usual", which will use glyphs from proportional fonts with monospaced advance width, and which will use monospaced fonts? Because currently I'm utterly confused regarding what you'd like to change there and how. And consequently, I don't understand what are the benefits of making such changes.