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.bugs Subject: bug#55696: 28.1; eshell fails to respect text-scale-increase Date: Sun, 05 Jun 2022 12:13:06 +0300 Message-ID: <83sfoja2xp.fsf@gnu.org> References: <37af046b-4257-6370-c765-9290eae73fd4@gmail.com> <831qw6dzra.fsf@gnu.org> <0278e759-237b-a32b-4b1f-fbdacf39c8ef@gmail.com> <83pmjpar0x.fsf@gnu.org> <9e8a8b42-2f42-3027-2ec0-97744bb91911@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12148"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 55696@debbugs.gnu.org, jeff.kowalski@gmail.com To: Jim Porter , martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 05 11:14:38 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1nxmLD-0002pJ-Tm for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jun 2022 11:14:36 +0200 Original-Received: from localhost ([::1]:58482 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nxmLC-0005fB-31 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jun 2022 05:14:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52354) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxmKh-0005dr-0v for bug-gnu-emacs@gnu.org; Sun, 05 Jun 2022 05:14:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37944) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nxmKf-0006bA-OX for bug-gnu-emacs@gnu.org; Sun, 05 Jun 2022 05:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nxmKf-0006mo-JH for bug-gnu-emacs@gnu.org; Sun, 05 Jun 2022 05:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Jun 2022 09:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55696 X-GNU-PR-Package: emacs Original-Received: via spool by 55696-submit@debbugs.gnu.org id=B55696.165442040726037 (code B ref 55696); Sun, 05 Jun 2022 09:14:01 +0000 Original-Received: (at 55696) by debbugs.gnu.org; 5 Jun 2022 09:13:27 +0000 Original-Received: from localhost ([127.0.0.1]:60074 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxmK7-0006ls-FK for submit@debbugs.gnu.org; Sun, 05 Jun 2022 05:13:27 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39108) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxmK5-0006lf-Sf for 55696@debbugs.gnu.org; Sun, 05 Jun 2022 05:13:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40440) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxmK0-0006Yi-H1; Sun, 05 Jun 2022 05:13:20 -0400 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=2PzDpV2Mu4Eeta6emK/rAkqa1LmRpY79l0vNRvRaN6E=; b=QHoRhNraITy4 miLTo8TrTfxhx4mkYpQ1upbyLGyxQp0sQNJjjlhbTOUCHP7n09L4LkANKnAfghFQLZa95YlhhDWCH AYS1W1MqCGO44fN0n0RvhpiO5OsJ30hx7yzjR+4hkOdfAD8LqT4I+L3WY7ZXMs6czFtvoSsemyFf3 B861fM+9R9xfBXhI82lHiBR6kIoDRKoZFgHANMcKN2MbYNTJkoUJV81FZZKbevDQlwnu17ckCy5NZ +voB+YqwoV2hqMkMdJvTl0LPXimUeIct391r1dszNIFIHQMs1aZg+IyMtJcHiF1ntLsblJsxV/JBt rZPkXDdOKV5soRVb6R3Bww==; Original-Received: from [87.69.77.57] (port=1851 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 1nxmJz-0000Q2-VN; Sun, 05 Jun 2022 05:13:20 -0400 In-Reply-To: <9e8a8b42-2f42-3027-2ec0-97744bb91911@gmail.com> (message from Jim Porter on Sat, 4 Jun 2022 21:49:40 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:233696 Archived-At: > Cc: 55696@debbugs.gnu.org, jeff.kowalski@gmail.com > From: Jim Porter > Date: Sat, 4 Jun 2022 21:49:40 -0700 > > On 6/3/2022 11:20 PM, Eli Zaretskii wrote: > > I suggest that you try, it shouldn't be too hard. Look at what > > window-font-height does, its main job is done in C as well, so you can > > call those functions directly from C, or do the same "by hand". Feel > > free to ask questions if something is not clear. > > Ok, here's an updated patch. Hopefully I got everything reasonably close > to correct. I chose to add a new meaning for the PIXELWISE argument to > `window-body-(width|height)' (and rename it to UNIT), since each of the > three cases (canonical character size, remapped character size, and > pixels) are all mutually-exclusive. Thanks. I'd prefer to avoid the renaming of the argument, as there's nothing wrong with PIXELWISE being not a boolean value. We have this elsewhere; e.g., see line-number-display-width. > > My point is that "partly off-screen" might mean 1 or 2 pixels > > off-screen, something that users will usually not even see, because > > those pixels are unused by most glyphs. So maybe some heuristics is > > more pertinent, like rounding up only when the result is "almost" one > > more line. > > > > But if you are okay with "losing" a line in these cases, it's fine by > > me. > > Since `window-body-(width|height)' round down by default, I think it > makes sense to do that when those functions account for face remapping > as well. Either rounding behavior would probably be ok for Eshell, but > this way seems like the least surprising to users of these functions in > general. OK. > +If @var{unit} is @code{remap} and the default face is remapped > +(@pxref{Face Remapping}), use the remapped face to determine the > +character height. For any other value, return the height in pixels. ^^^^^^^^^^^^^^^^^^^ "For any other non-@code{nil} value" avoids potential confusion here. > +If @var{unit} is @code{remap} and the default face is remapped > +(@pxref{Face Remapping}), use the remapped face to determine the > +character width. For any other value, return the width in pixels. Same here. > +static enum body_unit > +window_body_unit_from_symbol(Lisp_Object unit) > +{ > + return > + (unit == intern("remap") ? BODY_IN_REMAPPED_CHARS > + : NILP (unit) ? BODY_IN_CANONICAL_CHARS > + : BODY_IN_PIXELS); Our style in C is to leave one space between the name of a symbol and the following left parenthesis. So: window_body_unit_from_symbol (Lisp_Object unit) intern ("remap") > @@ -1029,11 +1038,22 @@ window_body_height (struct window *w, bool pixelwise) > - WINDOW_MODE_LINE_HEIGHT (w) > - WINDOW_BOTTOM_DIVIDER_WIDTH (w)); > > + int denom = 1; > + if (unit == BODY_IN_CANONICAL_CHARS) > + { > + denom = FRAME_LINE_HEIGHT (WINDOW_XFRAME (w)); > + } > + else if (unit == BODY_IN_REMAPPED_CHARS) > + { > + struct frame *f = XFRAME (WINDOW_FRAME (w)); > + int face_id = lookup_named_face (NULL, f, Qdefault, true); > + struct face *face = FACE_FROM_ID_OR_NULL (f, face_id); > + if (face && face->font && face->font->height) > + denom = face->font->height; > + } I think we should optimize the frequent case where Vface_remapping_alist is nil, in which case BODY_IN_REMAPPED_CHARS is the same as BODY_IN_CANONICAL_CHARS. lookup_named_face is not a trivial function, so it is best to avoid calling it whenever possible. > +The optional argument UNIT defines the units to use for the width. If > +nil, return the largest integer smaller than WINDOW's pixel width > +divided by the character width of WINDOW's frame. I prefer saying "in units of ..." rather than 'divided by ...". The latter is slightly harder to grasp, IME. > This means that if > +a column at the right of the text area is only partially visible, that > +column is not counted. I think this sentence doesn't have to be in the doc string; it's enough to have this explanation in the manual. (Please make the same change in other similar places.) Martin, any further comments?