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

[Eli Zaretskii <eliz@gnu.org>]

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