bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes

[martin rudalics <rudalics@gmx.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