frame size

[Luc Teirlinck]

The Elisp documentation and the docstrings concerning the functions
allowing to access or set frame height and width is at many places
unclear or contradicts the actual behavior.  The actual behavior is
very counterintuitive.  Let us first look at the character oriented
functions.

Elisp doc of `height parameter':

`height'
     The height of the frame contents, in characters.  (To get the
     height in pixels, call `frame-pixel-height'; see *Note Size and
     Position::.)

>From docstring of `frame-height':

     Return number of lines available for display on frame.

How can anybody guess from this that the tool bar is included in the
height, but the menu bar is not?  It is easy enough to explicitly
mention this in both places, but does the "feature" _itself_ make sense?

Worse.  Do `emacs -q &'.

ELISP> (setq frame (make-frame'((height . 10))))
#<frame address@hidden 0x88047f8>
ELISP> (frame-parameter frame 'height)
13

>From things I vaguely remember, this might actually be a deliberate
"feature", but whatever one wanted to achieve with this "feature"
(assuming it was deliberate), there _must_ be a better way than with
the above.  (See, for instance, solution (3) below.)  Note that
(set-frame-height frame 10) will indeed set the height parameter to
10, as expected.

For the character-oriented size functions, I like the current behavior for
the width.  One usually knows how many columns one wants and this is
not altered by scrollbars or fringes.  Hence they should only count
text columns, as they do, up to a bug which I will report separately.

But for the height, there is no fixed size one could possibly need: it
depends on the concrete situation.  What one usually wants is as much
as possible.  The `fullscreen' frame parameter is very often not the
right thing to use, because there usually is stuff that one does not
want to cover up (panels or whatever).

So for the height there are (at least) three possibilities:

1.  Keep the current situation and fix the documentation.

2.  Include _both_ menu bar _and_ tool bar in the height (for all
    involved functions).  This is the solution I prefer.  For instance
    when I try to gain a line by disabling the menu bar, I still have
    to change my frame size to get the desired result.  If I then want
    the menu bar back, I have to resize my frame again to prevent it
    from covering up stuff.  If I change my mind more permanently
    about using menu bar or tool bar, I have to reset my geometry in
    all places where I customized it (several).  I believe that going
    for this solution would eliminate all these nuisances.

3.  Include _neither_ menu bar _nor_ tool bar in the frame height (for
    all involved functions).  I like this less than (2), but vastly
    prefer it over (1).  This solution consistently assumes that
    somebody who customizes a frame height usually worries about a
    fixed number of available lines, rather than about getting the
    maximum amout without covering up stuff.  This assumption is
    definitely wrong in my case.  I believe that it is wrong for at
    least 99% of users.  But if one is going to make this assumption,
    it is better to at least be _consistent_ about it.  That way one
    would at least avoid the surprise pointed out in the above ielm
    run, as well as other surprises.

Sincerely,

Luc.