From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#20022: 24.4.90; window-body-height, window-body-width wrong value after text-scale-adjust Date: Sun, 08 Mar 2015 05:47:32 +0200 Message-ID: <83mw3okv57.fsf@gnu.org> References: <874mpx3gh2.fsf@gmail.com> <83a8zpm92q.fsf@gnu.org> <87vbic23j5.fsf@gmail.com> <83pp8kllrh.fsf@gnu.org> <87oao41qo3.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1425786507 11439 80.91.229.3 (8 Mar 2015 03:48:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Mar 2015 03:48:27 +0000 (UTC) Cc: 20022@debbugs.gnu.org To: Vitalie Spinu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 08 04:48:13 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YUSCI-0008Eb-5K for geb-bug-gnu-emacs@m.gmane.org; Sun, 08 Mar 2015 04:48:10 +0100 Original-Received: from localhost ([::1]:37376 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUSCH-0007cM-98 for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Mar 2015 22:48:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43060) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUSCD-0007cG-V5 for bug-gnu-emacs@gnu.org; Sat, 07 Mar 2015 22:48:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YUSCA-0003lq-PC for bug-gnu-emacs@gnu.org; Sat, 07 Mar 2015 22:48:05 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUSCA-0003ll-Ks for bug-gnu-emacs@gnu.org; Sat, 07 Mar 2015 22:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YUSCA-0002CO-9I for bug-gnu-emacs@gnu.org; Sat, 07 Mar 2015 22:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 08 Mar 2015 03:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20022 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20022-submit@debbugs.gnu.org id=B20022.14257864808443 (code B ref 20022); Sun, 08 Mar 2015 03:48:02 +0000 Original-Received: (at 20022) by debbugs.gnu.org; 8 Mar 2015 03:48:00 +0000 Original-Received: from localhost ([127.0.0.1]:39016 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YUSC7-0002C6-AV for submit@debbugs.gnu.org; Sat, 07 Mar 2015 22:47:59 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:65248) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YUSC3-0002Br-UQ for 20022@debbugs.gnu.org; Sat, 07 Mar 2015 22:47:57 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NKV00I00JUYQW00@a-mtaout22.012.net.il> for 20022@debbugs.gnu.org; Sun, 08 Mar 2015 05:47:49 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NKV00IIZJVOJK90@a-mtaout22.012.net.il>; Sun, 08 Mar 2015 05:47:49 +0200 (IST) In-reply-to: <87oao41qo3.fsf@gmail.com> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:100250 Archived-At: > From: Vitalie Spinu > Cc: 20022@debbugs.gnu.org > Date: Sat, 07 Mar 2015 22:46:52 +0200 > > >>> Eli Zaretskii on Sat, 07 Mar 2015 20:12:34 +0200 wrote: > > > having a term that needs to be explained by telling how to compute it > > sends a confusing message. > > It gives an operational definition of "lines", which is a valid > definition. An operational definition doesn't really define anything. What it does is tell the reader that the term itself is not what it looks like. So it doesn't help much in this case, where the term is vague to begin with. > It's confusing to see 100 lines in a buffer and to be told that > there are 25 "lines". Yes, it is. Which is why this issue is hard to explain. Things get less confusing once you realize that these are just units to measure window dimensions, not a means to tell how many characters will fit. > >> I simply need the number of characters that can be fit in a single line > >> in order to set the sub-process output width. > > > This can only be meaningfully computed if the text emitted by the > > subprocess will be rendered in its entirety using the default face. > > Sure, but that's the case of window-height as well. It's based on the > size of a particular font regardless of what's contained in the buffer. I'm asking whether this is a frequent enough use case. Even Grep and compilation buffers use several faces, which violates this assumption. As Emacs moves more and more towards variable-face text, there will be fewer use cases where this will be true. > > Not that I know of. We could provide a function for that, if this > > functionality is deemed important enough. > > I guess the core of the problem is that having a width/height computed > using default buffer font is more useful than using frame default > font. See above: those measurement units were just that. > Given that the docs were never clear maybe the behavior of > existing functions could be changed. No, too much code depends on that. Like the functions that resize windows, for example. > Or an additional font-toggling argument added to those. I'd rather we provided a separate set of functions for that (since the implementation is quite different). Assuming that a fixed font is a popular enough use case, that is.