GNU bug report logs - #20022
24.4.90; window-body-height, window-body-width wrong value after text-scale-adjust

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20022 in the body.
You can then email your comments to 20022 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vitalie Spinu <spinuvit <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.90; window-body-height, window-body-width wrong value after
 text-scale-adjust
Date: Sat, 07 Mar 2015 00:31:53 +0200

After text-scale-adjust [C-x C-] window-height and window-width return
the old (original) value.

The doc says:

 This function returns the height, in lines, of the body of window
 WINDOW.

So at least the docs are imprecise or incomplete.

Relatedly, there seems to be no way to determine the height/width of a
character in pixels after rescaling. `frame-char-width` returns the
original size.


Thanks, 

  Vitalie


In GNU Emacs 24.4.90.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
 of 2015-02-20 on galago
Repository revision: 35f047c06603ce2e549e43ba38de0e61083b0311
Windowing system distributor `The X.Org Foundation', version 11.0.11600000
System Description:	Ubuntu 14.10

Message #8 received at 20022 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Vitalie Spinu <spinuvit <at> gmail.com>, 20022 <at> debbugs.gnu.org
Subject: Re: bug#20022: 24.4.90; window-body-height, window-body-width wrong
 value after text-scale-adjust
Date: Sat, 07 Mar 2015 10:41:23 +0100

> After text-scale-adjust [C-x C-] window-height and window-width return
> the old (original) value.

Because it did not change.

> The doc says:
>
>   This function returns the height, in lines, of the body of window
>   WINDOW.
>
> So at least the docs are imprecise or incomplete.

Here the doc also says:

  If WINDOW's pixel height is not an integral multiple of its frame's
  character height, the number of lines occupied by WINDOW is rounded
  internally.  This is done in a way such that, if WINDOW is a parent
  window, the sum of the total heights of all its children internally
  equals the total height of WINDOW.

  If the optional argument ROUND is `ceiling', return the smallest
  integer larger than WINDOW's pixel height divided by the character
  height of WINDOW's frame.  ROUND `floor' means to return the largest
  integer smaller than WINDOW's pixel height divided by the character
  height of WINDOW's frame.  Any other value of ROUND means to return
  the internal total height of WINDOW.

> Relatedly, there seems to be no way to determine the height/width of a
> character in pixels after rescaling. `frame-char-width` returns the
> original size.

Because IIUC the values might differ according to the window where the
character is displayed.  I don't know how to get the value you want.
ISTR that someone is currently working on this.

martin

Message #11 received at 20022 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vitalie Spinu <spinuvit <at> gmail.com>
Cc: 20022 <at> debbugs.gnu.org
Subject: Re: bug#20022: 24.4.90;
 window-body-height, window-body-width wrong value
 after	text-scale-adjust
Date: Sat, 07 Mar 2015 11:49:01 +0200

> From: Vitalie Spinu <spinuvit <at> gmail.com>
> Date: Sat, 07 Mar 2015 00:31:53 +0200
> 
> After text-scale-adjust [C-x C-] window-height and window-width return
> the old (original) value.

As designed: the value is measured in canonical character units.

> The doc says:
> 
>  This function returns the height, in lines, of the body of window
>  WINDOW.

It says much more than that.  In particular, it mentions "the
character height of WINDOW's frame", which should be a hint.  The
ELisp manual explicitly says "frame's default character height".

> So at least the docs are imprecise or incomplete.

Suggestions to how to make them more complete without confusing users
(who might not even know that the size of the default face's font can
be changed, or that text-scale-adjust exists at all) are welcome.

IOW, there's a problem here: we need to provide a description that
will make sense both to relative newbies and to sophisticated Lisp
programmers alike.  The current doc string is an attempt to do so.  If
you (or someone else) can suggest a better wording for that, it will
be most welcome.

> Relatedly, there seems to be no way to determine the height/width of a
> character in pixels after rescaling. `frame-char-width` returns the
> original size.

You want default-font-height, I think.  (A similar functionality for
width can be used based on font-info modifications on the master
branch only, but you could approximate that by assuming the same ratio
between the canonical width and the rescaled width as between the
canonical height and rescaled height.)

For the line height, don't forget the line-spacing issue, which is
taken into account by the default-line-height function.

(Btw, I'm not sure how you get from window-width/height to
width/height of a character; I suspect that you might be trying to
compute something for which helpful functions already exist, so you
are encouraged to tell more details.)

Message #14 received at 20022 <at> debbugs.gnu.org (full text, mbox):

From: Vitalie Spinu <spinuvit <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20022 <at> debbugs.gnu.org
Subject: Re: bug#20022: 24.4.90;
 window-body-height, window-body-width wrong value
 after	text-scale-adjust
Date: Sat, 07 Mar 2015 18:09:02 +0200

 >>> Eli Zaretskii on Sat, 07 Mar 2015 11:49:01 +0200 wrote:

 >> After text-scale-adjust [C-x C-] window-height and window-width return
 >> the old (original) value.

 > As designed: the value is measured in canonical character units.

The doc string of of `window-body-width` and `window-body-height` don't
even mention the measurement unit. The docs can easel be more
explicit. Something along the following lines:

  Return the height of WINDOW's text area in canonical lines. The height
  of a canonical line is given by `frame-char-height`.

 > The ELisp manual explicitly says "frame's default character height".

Ok, thanks. This one is in the preamble of 27.3 Window Sizes manual page. I
have missed that paragraph completely.

BTW, the "width of a “default” character" is confusing as of the
conflicting meaning with the `default-font-height`. "Canonical" is a
better term IMO.

 > You want default-font-height, I think.  (A similar functionality for
 > width can be used based on font-info modifications on the master
 > branch only, but you could approximate that by assuming the same ratio
 > between the canonical width and the rescaled width as between the
 > canonical height and rescaled height.)
 > For the line height, don't forget the line-spacing issue, which is
 > taken into account by the default-line-height function.

Uff. That's rather complicated :(

 > I suspect that you might be trying to compute something for which
 > helpful functions already exist, so you are encouraged to tell more
 > details.

I simply need the number of characters that can be fit in a single line
in order to set the sub-process output width.

Building on your "approximation" trick, I can get an approximate width
in pixels of the character, then divide the width of the window in
pixels by this width to get the approximate number of characters. Is
there an easier way?

Thanks,

  Vitalie

Message #17 received at 20022 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Vitalie Spinu <spinuvit <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 20022 <at> debbugs.gnu.org
Subject: Re: bug#20022: 24.4.90; window-body-height, window-body-width wrong
 value after	text-scale-adjust
Date: Sat, 07 Mar 2015 18:58:26 +0100

> Building on your "approximation" trick, I can get an approximate width
> in pixels of the character, then divide the width of the window in
> pixels by this width to get the approximate number of characters. Is
> there an easier way?

See also Bug#19194 and Bug#19395.

martin

Message #20 received at 20022 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vitalie Spinu <spinuvit <at> gmail.com>
Cc: 20022 <at> debbugs.gnu.org
Subject: Re: bug#20022: 24.4.90;
 window-body-height, window-body-width wrong value
 after	text-scale-adjust
Date: Sat, 07 Mar 2015 20:12:34 +0200

> From: Vitalie Spinu <spinuvit <at> gmail.com>
> Cc: 20022 <at> debbugs.gnu.org
> Date: Sat, 07 Mar 2015 18:09:02 +0200
> 
>  >>> Eli Zaretskii on Sat, 07 Mar 2015 11:49:01 +0200 wrote:
> 
>  >> After text-scale-adjust [C-x C-] window-height and window-width return
>  >> the old (original) value.
> 
>  > As designed: the value is measured in canonical character units.
> 
> The doc string of of `window-body-width` and `window-body-height` don't
> even mention the measurement unit.

It says "divided by the character width".

> The docs can easel be more
> explicit. Something along the following lines:
> 
>   Return the height of WINDOW's text area in canonical lines. The height
>   of a canonical line is given by `frame-char-height`.

If there's agreement that mentioning canonical lines will make this
clear (personally, I'm not sure), I'm fine with that.  But adding the
sentence about frame-char-height IMO just muddies the water: having a
term that needs to be explained by telling how to compute it sends a
confusing message.

> BTW, the "width of a “default” character" is confusing as of the
> conflicting meaning with the `default-font-height`. "Canonical" is a
> better term IMO.

They are both vague, and need a lot of explanations to fully
understand.  Luckily, most people don't need to.

> 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.
If that's what you need, it should be easy to provide such a function,
but I don't think we have it now.  Martin might have some tricks up
his sleeve, though.

> Building on your "approximation" trick, I can get an approximate width
> in pixels of the character, then divide the width of the window in
> pixels by this width to get the approximate number of characters. Is
> there an easier way?

Not that I know of.  We could provide a function for that, if this
functionality is deemed important enough.

Message #23 received at 20022 <at> debbugs.gnu.org (full text, mbox):

From: Vitalie Spinu <spinuvit <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20022 <at> debbugs.gnu.org
Subject: Re: bug#20022: 24.4.90;
 window-body-height, window-body-width wrong value
 after	text-scale-adjust
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. It's confusing to see 100 lines in a buffer and to be told
that there are 25 "lines".

 >> 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.

 > 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. Given that the docs were never clear maybe the behavior of
existing functions could be changed. Or an additional font-toggling
argument added to those.

  Vitalie

Message #26 received at 20022 <at> debbugs.gnu.org (full text, mbox):

From: Vitalie Spinu <spinuvit <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 20022 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#20022: 24.4.90;
 window-body-height, window-body-width wrong value
 after	text-scale-adjust
Date: Sat, 07 Mar 2015 22:49:32 +0200

 >>> martin rudalics on Sat, 07 Mar 2015 18:58:26 +0100 wrote:

 > See also Bug#19194 and Bug#19395.

Indeed, this issue seems to be a duplicate of Bug#19194.

  Vitalie

Message #29 received at 20022 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vitalie Spinu <spinuvit <at> gmail.com>
Cc: 20022 <at> debbugs.gnu.org
Subject: Re: 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

> From: Vitalie Spinu <spinuvit <at> gmail.com>
> Cc: 20022 <at> 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.

Message #32 received at 20022 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Vitalie Spinu <spinuvit <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 20022 <at> debbugs.gnu.org
Subject: Re: bug#20022: 24.4.90; window-body-height, window-body-width wrong
 value after	text-scale-adjust
Date: Sun, 08 Mar 2015 11:03:26 +0100

> 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. Given that the docs were never clear maybe the behavior of
> existing functions could be changed. Or an additional font-toggling
> argument added to those.

You mean that switching to another buffer in a window could change the
nominal height of that window?

I have no opinion on this because I don't care about line-/column values
returned by these functions.  The only thing I do care about is that if
you have two side-by-side windows, the value of `window-left-column' of
the right window equals the sum of `window-left-column' and
`window-total-width' of the window on the left.  Otherwise, windmove's
functions might fail and I have no intention to fix them again.

martin

Message #37 received at 20022 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Joe Corneli <holtzermann17 <at> gmail.com>
Cc: 20022 <at> debbugs.gnu.org, 19194 <at> debbugs.gnu.org
Subject: Re: bug#20022: 24.4.90; window-body-height, window-body-width wrong
 value after text-scale-adjust
Date: Thu, 10 Feb 2022 09:16:04 +0100

Joe Corneli <holtzermann17 <at> gmail.com> writes:

> Adjusting the font size, I would expect that the window's "body width"
> would change -- more characters can be fit into the same amount of
> screen space.  Current behaviour does not match this expectation.
>
> M-: (window-body-width) RET  [Note result.]
> C-x C--
> M-: (window-body-width) RET  [Result is the same.]
>
> The function is described:
>
> "This function returns the width, in columns, of the body of window
> window."
>
> If for some reason the "nominal" number of columns needs to calculated
> with reference to the default font, then there should be another
> function to return the "actual" number of columns.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Skimming this thread, I think the conclusion here is that these
functions work as designed.  `C-x C--' reduces the size of the font in
the current buffer, but the "window body width" concept remains the
same.  (I.e., if you create a new buffer and display it, that's what
`window-body-width' is telling you the number of columns for.)

So I don't think there's anything to do here, and I'm closing this bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #44 received at 20022 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Joe Corneli <holtzermann17 <at> gmail.com>
Cc: "20022 <at> debbugs.gnu.org" <20022 <at> debbugs.gnu.org>,
 "19194 <at> debbugs.gnu.org" <19194 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#19194: bug#20022: 24.4.90; window-body-height,
 window-body-width wrong value after text-scale-adjust
Date: Thu, 10 Feb 2022 17:39:44 +0000

[Message part 1 (text/plain, inline)]

> > Adjusting the font size, I would expect that the window's "body width"
> > would change -- more characters can be fit into the same amount of
> > screen space.  Current behaviour does not match this expectation.
> >
> > M-: (window-body-width) RET  [Note result.]
> > C-x C--
> > M-: (window-body-width) RET  [Result is the same.]
> >
> > The function is described:
> >
> > "This function returns the width, in columns, of the body of window
> > window."
> >
> > If for some reason the "nominal" number of columns needs to calculated
> > with reference to the default font, then there should be another
> > function to return the "actual" number of columns.
> 
> Skimming this thread, I think the conclusion here is that these
> functions work as designed.  `C-x C--' reduces the size of the font in
> the current buffer, but the "window body width" concept remains the
> same.  (I.e., if you create a new buffer and display it, that's what
> `window-body-width' is telling you the number of columns for.)
> 
> So I don't think there's anything to do here, and I'm closing this bug
> report.

The functions work as designed, yes.  But the design
could be improved.

You can decide whether this comment is relevant to
this bug report.  I think it's related, but it's not
exactly the same suggestion/problem.

I've proposed an enhancement to optionally resize
the window to fit the newly displayed text -
shrinking the text shrinks the window etc.  This
enhancement can free up frame or screen real estate
for other windows or frames.

This is not the same as the enhancement hinted at
in this bug report, which I guess is instead to
reflow the text to accommodate/fill the space
provided by the changed text size.  That makes
sense especially if `visual-line-mode' is used.
The enhancement I describe makes sense especially
if that mode is not used.

I've suggested my enhancement before, but it was
rejected, even though it's behavior change is
optional.  I describe it again here, FWIW.

I provide the enhancement in the tiny bit of code
that is library `face-remap+.el' (attached).  It
provides a user option, `text-scale-resize-window',
and it redefines `text-scale-increase' to respect
that option.  A patch is trivial.

[face-remap+.el (application/octet-stream, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.