From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes Date: Thu, 27 Nov 2014 19:35:25 +0100 Message-ID: <54776EED.9090303@gmx.at> References: <87h9xm6plp.fsf@gmail.com> <5476F298.5000205@gmx.at> <87ppc8rk08.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1417113395 26765 80.91.229.3 (27 Nov 2014 18:36:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Nov 2014 18:36:35 +0000 (UTC) Cc: 19194@debbugs.gnu.org To: Joe Corneli Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 27 19:36:28 2014 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 1Xu3vX-0003MR-Is for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Nov 2014 19:36:27 +0100 Original-Received: from localhost ([::1]:41192 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xu3vX-0007P3-4i for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Nov 2014 13:36:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xu3vL-0007Ip-TE for bug-gnu-emacs@gnu.org; Thu, 27 Nov 2014 13:36:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xu3v8-0004qW-Ph for bug-gnu-emacs@gnu.org; Thu, 27 Nov 2014 13:36:15 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50681) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xu3v8-0004qR-MU for bug-gnu-emacs@gnu.org; Thu, 27 Nov 2014 13:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xu3v8-0001mn-Fx for bug-gnu-emacs@gnu.org; Thu, 27 Nov 2014 13:36:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Nov 2014 18:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19194 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19194-submit@debbugs.gnu.org id=B19194.14171133396794 (code B ref 19194); Thu, 27 Nov 2014 18:36:02 +0000 Original-Received: (at 19194) by debbugs.gnu.org; 27 Nov 2014 18:35:39 +0000 Original-Received: from localhost ([127.0.0.1]:47887 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xu3ul-0001lV-CS for submit@debbugs.gnu.org; Thu, 27 Nov 2014 13:35:39 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:60354) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xu3uh-0001lL-9Y for 19194@debbugs.gnu.org; Thu, 27 Nov 2014 13:35:36 -0500 Original-Received: from [188.22.37.213] ([188.22.37.213]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lfjxq-1YHoru09lq-00pINH; Thu, 27 Nov 2014 19:35:32 +0100 In-Reply-To: <87ppc8rk08.fsf@gmail.com> X-Provags-ID: V03:K0:2Pp1RRsxN5BN7NBLIAmeWIRCYtKVvww/3Rj/hipjR/K7pmLNkJI u8aoyGTdrQyWJJJdEngaP9NO3e7x7XxB/fLHUNps3lasDafoRmh0csmQc6/2ccbQQC4jt88 fRLlgzV/osH3CxRjQUfoZ7O3nHeCtBW8HhHcRakPE1LIOvQ9NhBMl3OvDdgQKkT0xfgG2xJ Uzl2/O3Bi/eSb8kx5rZsA== X-UI-Out-Filterresults: notjunk:1; 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:96677 Archived-At: > I think you are totally right. To keep the buffer and window > distinction properly, my note should probably be read as a feature > request, not a bug report. The request is for a function such as > `buffer-body-width' that would return the width of the current displayed > buffer in em-length units. What is the width of a buffer? What are em-lenght units? > Sounds promising! I just pressed C-x C-- which runs `text-scale-adjust' > to the effect: "Decrease the default face height by one step". That's incorrect. The doc-string of `text-scale-decrease' tells it more accurately: "Decrease the height of the default face in the current buffer by DEC steps." > The step > is `text-scale-mode-step', unchanged from its default value of 1.2. The > number of steps looks to be stored buffer-locally as > `text-scale-mode-amount'. > > ... So a candidate function would be: > > (defun buffer-body-width (&optional buffer pixelwise) > (let ((width (window-body-width (get-buffer-window (or buffer > (current-buffer))) > pixelwise))) > (floor (cond > ((eq text-scale-mode-amount 0) > width) > ((> text-scale-mode-amount 0) > (/ width (* text-scale-mode-step text-scale-mode-amount))) > ((< text-scale-mode-amount 0) > (* width (* -1 text-scale-mode-step text-scale-mode-amount))))))) We could start from here. But: (1) `text-scale-mode-amount' is not autoloaded, so we get an error calling this with emacs -Q. (2) `text-scale-mode-amount' is buffer-local. So we have to choose the right buffer before evaluating it. (3) `text-scale-mode-amount' constitutes a request to the display engine to scale a face height. What shall we do when our target machine can't display the character with the requested height and uses, for example, the nearest available height instead? (4) I don't know whether and how the frame's `font' parameter can/should affect the height of the "default face". Likely this is not a problem - Eli will tell. As I said before, I'd rather have a buffer-local equivalent of the variable `frame-char-height', something like `buffer-char-height', instead of having to find out by myself what the correct value is. Next we should try to incorporate this in `window-body-height', either by overloading the PIXELWISE argument - for example, if this is the symbol `lines-scaled' we'd return the scaled lines - or with an extra BUFFER argument which would also allow to retrieve the body height of a window as if it displayed BUFFER or with something better yet ... As a consequence, we'd probably have to rename the current C routine `window-body-height' to `window-body-height-internal' and write the new `window-body-height' in Elisp on top of that. And finally we would have to do that for all related functions like `window-total-height', `split-window' or `window-resize' and decide how a user can specify that, when splitting a window via say C-4 C-x 2, the top window should have four lines counted in the original window buffer's text scaling. martin