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: Sat, 04 Jun 2022 09:20:30 +0300 Message-ID: <83pmjpar0x.fsf@gnu.org> References: <37af046b-4257-6370-c765-9290eae73fd4@gmail.com> <831qw6dzra.fsf@gnu.org> <0278e759-237b-a32b-4b1f-fbdacf39c8ef@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8204"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 55696@debbugs.gnu.org, jeff.kowalski@gmail.com To: Jim Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 04 08:22:09 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 1nxNAm-0001zA-Nz for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jun 2022 08:22:09 +0200 Original-Received: from localhost ([::1]:49268 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nxNAk-0000rw-Ts for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jun 2022 02:22:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51316) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxN9l-0000rT-PJ for bug-gnu-emacs@gnu.org; Sat, 04 Jun 2022 02:21:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35343) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nxN9j-0002Rb-PS for bug-gnu-emacs@gnu.org; Sat, 04 Jun 2022 02:21:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nxN9i-0003K6-Ig for bug-gnu-emacs@gnu.org; Sat, 04 Jun 2022 02:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Jun 2022 06:21:02 +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.165432363112727 (code B ref 55696); Sat, 04 Jun 2022 06:21:02 +0000 Original-Received: (at 55696) by debbugs.gnu.org; 4 Jun 2022 06:20:31 +0000 Original-Received: from localhost ([127.0.0.1]:57473 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxN9C-0003JC-Ix for submit@debbugs.gnu.org; Sat, 04 Jun 2022 02:20:30 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38098) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxN96-0003Iv-VD for 55696@debbugs.gnu.org; Sat, 04 Jun 2022 02:20:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45256) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxN90-0002Jd-2a; Sat, 04 Jun 2022 02:20:19 -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=rktA2XMnzCiYNxi20UuqVsmGqRGy1wKj9mLCcPprez8=; b=BS9tg3o1NAb+ pZV1hUB5nqU53NBa9ucqKv+vPp7NTgJ6T8cKdKZ1gnlS/dpzhDnU0mnfWaJhSIjz9cbWAwDypEkyc KA12ARUEZbdjJdjOiFyTVpu7f64xO1Re1YYJNXQ7SYPesMaZho/V0FzX5rqwvyWMy8XWLisbpqYaG Qb89NUssHmk6+jsfJWcVPICEtxXJ9Xmd8j4EFrrVcI7s+d/GkGbnRVduJTi2DyPWdMlM1Lv0ET9Ib vDE5GBZgzsdpv7lZkLeWdSMNN9dSBpFaYqkBd6snrL0sKX6yEjdVd/mbawtg5qxiZnU7hgFtPJBSj stcCIcVaCqmQC1HlFNXyJg==; Original-Received: from [87.69.77.57] (port=4717 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 1nxN8z-0007UF-G1; Sat, 04 Jun 2022 02:20:17 -0400 In-Reply-To: <0278e759-237b-a32b-4b1f-fbdacf39c8ef@gmail.com> (message from Jim Porter on Fri, 3 Jun 2022 13:30:01 -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:233637 Archived-At: > Cc: 55696@debbugs.gnu.org, jeff.kowalski@gmail.com > From: Jim Porter > Date: Fri, 3 Jun 2022 13:30:01 -0700 > > On 6/2/2022 11:31 PM, Eli Zaretskii wrote: > > Thanks, but I'm not too happy with adding such a function to Emacs. I > > understand why it could make sense for Eshell, or any other package > > that uses fixed-size characters, like terminal emulators in term.el. > > But in general, it makes no sense in Emacs to ask how many lines of a > > given non-default font can fit in a window, because you cannot > > guarantee that a single font will be used in the entire window -- it > > is enough to have some of the text having the bold or italic face > > attribute, or have some non-ASCII characters that will be displayed in > > a different font, to disrupt the results. > > While I don't have a strong opinion that this function should exist, I > think the scenario where it *could* be useful is to "make layout > decisions", as the Lisp manual says (for `window-max-chars-per-line'). > If you were making some UI in a Lisp program that wanted things to fit > in a window all at once, you'd likely know what face would get used (and > it might not be the default face). Then, you could use both > `window-max-chars-per-line' and `window-max-lines' to figure out how > much space you have. Layout decisions for a single line are much simpler, and more probable to succeed, than similar layout decisions for the entire window. The latter are all but impossible to do from Lisp, definitely not with a simplistic assumption of a single typeface being used for all the text in the window. We have window-text-pixel-size for the general case, for that very reason. But I think that function doesn't solve your problem, because you don't have text to measure when you make these decisions. > > We could perhaps make window-body-width and window-body-height > > optionally pay attention to the remapping of the default face, which > > should handle the case such as this one. Would that be acceptable for > > you? > > That works fine for me. I was actually surprised that these functions > didn't account for face remapping. There's no need to take face remapping into account as long as you measure in units of canonical character width and height. Face remapping is local to buffers, so it usually makes no sense to take the remapping into account by default, because a window can display any buffer. > Since window-body-(width|height) are C functions, it would be a bit more > work to implement this, but I'm sure someone familiar with writing > C-based Lisp functions wouldn't have much trouble. I could probably > figure out how to do it myself with a bit of digging too. 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. > >> + (with-selected-window (window-normalize-window window t) > >> + (let ((window-height (window-body-height window t)) > >> + (font-height (window-font-height window face))) > >> + (/ window-height font-height)))) > > > > Is integer division here really TRT? Shouldn't we round to the > > nearest integer instead of truncating? > > I think integer division is right, but there's an argument either way. I > see this function as asking the question, "How many lines can fully fit > in this window without scrolling?" If I had a GUI terminal window open > and it could fit 20.5 lines, I'd expect the $LINES variable in my shell > to be 20. That way, a program that consults that variable would know > that the 21st line is at least partly off-screen. 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. Thanks.