From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ingo Lohmar Newsgroups: gmane.emacs.bugs Subject: bug#37563: 27.0.50; fit-frame-to-buffer does not account for line-spacing Date: Thu, 03 Oct 2019 10:48:09 +0200 Message-ID: <87zhiixliu.fsf@kenko.localhost.com> References: <87tv8tsk3f.fsf@kenko.localhost.com> <87lfu4aook.fsf@kenko.localhost.com> <5b9fda23-4a2b-f5ff-5e49-22cdd4c857a5@gmx.at> <87d0fgamzj.fsf@kenko.localhost.com> <93140a98-fd99-7d55-0d5b-dd8c3c733521@gmx.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="126124"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 37563@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 03 10:49:16 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iFwnS-000Wd5-Fy for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Oct 2019 10:49:14 +0200 Original-Received: from localhost ([::1]:33896 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFwnR-00036G-CS for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Oct 2019 04:49:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43797) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFwnK-00035w-5T for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2019 04:49:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iFwnH-0008Be-Sx for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2019 04:49:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58162) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iFwnF-0008Au-V3 for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2019 04:49:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iFwnF-0002fu-Q6 for bug-gnu-emacs@gnu.org; Thu, 03 Oct 2019 04:49:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ingo Lohmar Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Oct 2019 08:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37563 X-GNU-PR-Package: emacs Original-Received: via spool by 37563-submit@debbugs.gnu.org id=B37563.157009251210243 (code B ref 37563); Thu, 03 Oct 2019 08:49:01 +0000 Original-Received: (at 37563) by debbugs.gnu.org; 3 Oct 2019 08:48:32 +0000 Original-Received: from localhost ([127.0.0.1]:38750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iFwmm-0002f9-88 for submit@debbugs.gnu.org; Thu, 03 Oct 2019 04:48:32 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:60273) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iFwmi-0002et-CF for 37563@debbugs.gnu.org; Thu, 03 Oct 2019 04:48:29 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id A40832400FD for <37563@debbugs.gnu.org>; Thu, 3 Oct 2019 10:48:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1570092501; bh=qqKaEPcYMkcvDdkuc7xipmXSYApmLzS9yaIj6o1ofTU=; h=From:To:Cc:Subject:Date:From; b=BO0fVGW/XUwnMJm9yT6jVQkPWD2+y459nKz5LXyzQwJZXYHsISdze3lFp4PWvCOLM ixCsHKCvC+MIbO1D3UUh7xx4XW68JpyYKgKc5kdFilwHTe0ubWIjFbTBIU859aG0m2 15szS5pAjL/yU+U7T7aFZxePARbnpUnBKhZDfrR9dgn982UK0wQkIz+49TfWzCJ4bf jAtX4Hv+HO2WeSS8rEy3QWxSwwvotBT62Hs6galvN59MSGbmO9JvDpZ+nxeTQemWHn sRlZdetAcHOr5H8QYZIYgdnxCq3HQVVTXrH9zDEpl7up7F4Z+q0GMnE80h4HotpjZL rTQBIJHiFK5JA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 46kRVW6lcSz9rxN; Thu, 3 Oct 2019 10:48:19 +0200 (CEST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.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" Xref: news.gmane.org gmane.emacs.bugs:168206 Archived-At: On Thu, Oct 03 2019 10:15 (+0200), martin rudalics wrote: > > Agreed. But if I change 'fit-frame-to-buffer', then, for consistency, > > I have to at least change 'fit-window-to-buffer' too. > > > > > + (setq height (* (/ (+ height line-height -1) line-height) > > > + line-height))) > > [...] > > > And then char-height can be dropped. > > > > Right. > > Hmm... Back to the roots, unfortunately. > > When we are here, 'height' is the calculated height the window should > have in pixels. When we want to communicate this value to the window > manager and 'frame-resize-pixelwise' is nil, we have to transform this > value (which already includes the pixels needed for line spacing) to a > multiple of the canonical character height of the frame and not the > line height we calculated earlier. So using 'line-height' here is not > the TRT unless I'm missing something. WDYT? Well, I don't really know :) I'm not totally sure about the meaning of `frame-resize-pixelwise'. 1) I think you're right in the sense that rounding to the line height (not the canonical char height) is NOT what the docstring says it does. That's bad and should be fixed either way. 2) With the above code, rounding window height (incl line spacing) to a multiple of the line height (incl line spacing), I do not see any effect of the option value; because it does not change the height value at all in my test cases (small popups). 3) BUT that's not generally true, IMO: If the height is restricted by the screen, or the margin calculation changes it, the rounding will have an effect. 4) *My interpretation* of `frame-resize-pixelwise' is that the default value, nil, has a single intention: To make the frame height an exact multiple of lines (and char width), mainly because of aesthetic reasons. In that case, I suggest we change the doc-string (which has some inaccurate phrasing and is a bit wordy, anyway) to say that it nil will round to a multiple of the default line height (incl line spacing).. Very briefly browsing the C code using the option seems to confirm that interpretation. So I think the code snippet as above is correct (using the line-height). I will try to come up with an updated docstring for `frame-resize-pixelwise', if you don't mind. As for the consistency changes that you mention, that sounds fine with me, you know the relevant much(!) better than I do. Ingo