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

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

[Vitalie Spinu]

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

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

[martin rudalics]

 > 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

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

[Eli Zaretskii]

> From: Vitalie Spinu <spinuvit@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.)

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

[Vitalie Spinu]

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

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

[martin rudalics]

 > 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

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

[Eli Zaretskii]

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

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

[Vitalie Spinu]

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

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

[Vitalie Spinu]

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

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

[Eli Zaretskii]

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

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

[martin rudalics]

 > 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