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: Variable pitch text filling Date: Mon, 29 Nov 2021 16:01:15 +0200 Message-ID: <83v90buklw.fsf@gnu.org> References: <87ilwft1ph.fsf@gnus.org> <837dcv2c2c.fsf@gnu.org> <875ysft0l3.fsf@gnus.org> <835yse3n01.fsf@gnu.org> <87lf1ars0f.fsf@gnus.org> <83czmm11t0.fsf@gnu.org> <87h7byrplm.fsf@gnus.org> <83a6hq0zey.fsf@gnu.org> <87lf19r7uv.fsf@gnus.org> <83tufxy7f0.fsf@gnu.org> <87zgpn13ce.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36421"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 29 15:09:56 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 1mrhLv-0009GK-Ql for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Nov 2021 15:09:56 +0100 Original-Received: from localhost ([::1]:39162 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mrhLu-00016y-Md for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Nov 2021 09:09:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53280) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mrhDQ-0004qZ-Bt for emacs-devel@gnu.org; Mon, 29 Nov 2021 09:01:12 -0500 Original-Received: from [2001:470:142:3::e] (port=43518 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 1mrhDL-0004tR-BP; Mon, 29 Nov 2021 09:01:08 -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=DI9Nko4+WdYgaqY1gx99XACxNFv+wBS7VvnXoYfEBVk=; b=l+K90kOdmSVS Tsx9qIcTebkKv1Tf/2uN84p5iIeUdby1jZR2DZJG7RIlynfSO69pVu4Z3mP9dEPrnnd/uaFof9CvK BC81jZucDqx7JADENm2hHcmJEzlBPi9PBXzKNfNy6fA3R9S7UTcpgH1CfR4L7ywLHJG+/+uCsF7GQ jlDUdL4kJUYKQXUvQoDqZ49yyWwcsErw6tg2l4kX+FgWqbHsdVjUyjsk3BUmDEvPgettyrlplZwB7 k6tHCK5FWJg8UtXYaxrnZZugWFuQPhCB4ThaeBpTsfF7LnbIWzlcF9XxIYoBoy228JGhrBI3R57tZ GD6IaVGViRTRX2iTEuhJRQ==; Original-Received: from [87.69.77.57] (port=2359 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 1mrhDK-0001HX-Sm; Mon, 29 Nov 2021 09:01:03 -0500 In-Reply-To: <87zgpn13ce.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 29 Nov 2021 14:46:57 +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:280478 Archived-At: > From: Lars Ingebrigtsen > Cc: emacs-devel@gnu.org > Date: Mon, 29 Nov 2021 14:46:57 +0100 > > Eli Zaretskii writes: > > >> Right. This reminds me -- perhaps we'd want to distribute the extra > >> space both before and after the glyph, to centre it within its allotted > >> width? > > > > I don't think so, because that would move the leftmost character away > > from the window-edge. > > Yes... but it that necessarily bad? Yes, IMO, because the text will seem to shift. It is also unnecessary, because having 2 pixels to the right of each character is practically indistinguishable from having one pixel on the left and 1 pixel on the right: you still end up with 2 pixels between any two characters. > > That's not the best possibility, because if some part of the affected > > text uses a smaller font, you'd see glyphs that are too-widely spaced? > > All these specs (`space' and whatnot) refer to FRAME_COLUMN_WIDTH in > their logic. (I mean, for those parts that aren't actual pixels.) Yes, but FRAME_COLUMN_WIDTH only reflects the dimensions of the frame's default face's font. If you use another face with a different (smaller) font, FRAME_COLUMN_WIDTH won't change. Think about a feature where footnotes are shown in a smaller font. > And I'm not quite sure what you mean here -- we're talking about > allowing people to "quantise" the widths to some common multiple, which > means that that is indeed what you'd see. But that's what the user > asked for. > > So mixing in smaller fonts in such a display wouldn't really be part of > the remit... I think it should be. Each face in Emacs has what I call "ASCII font": that's the face's font used for the ASCII (and usually also Latin) characters. My idea is to take the "standard" width from that ASCII font of the face. Then we can provide this feature for every possible face, and the result will be visually reasonable, since smaller faces will have smaller "standard" width, and will have fewer added pixels to the double-width characters displayed in that face. It's the same idea as I used for the enlarged height (which was rejected, but not because of this aspect), just for the width and not for the height.