frame size

frame size

[Luc Teirlinck]

Let us now look at the pixel oriented frame size functions:

Docstring of frame-pixel-height:

    Return a frame's height in pixels.
    This counts only the height available for text lines,
    not menu bars on window-system Emacs frames.

No way, it _does_ count menu bars (and tool bars) as well.  (At least
on GNU/Linux.)  Also, `frame-pixel-width' counts scroll bars, fringes
and the like.

Should we change the behavior or the documentation of
`frame-pixel-height' and `frame-pixel-width'?  I personally would
prefer to keep the code and change the documentation.

Sincerely,

Luc.

Re: frame size

[Richard Stallman]

    Should we change the behavior or the documentation of
    `frame-pixel-height' and `frame-pixel-width'?  I personally would
    prefer to keep the code and change the documentation.

Please do change the documentation.

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 emacs-21.3.50@swt40.swt.com 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.

Re: frame size

[Luc Teirlinck]

>From my previous message:

   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.

Sorry, I wrote this wrong.  I meant:

But for the height, there is no fixed _number of lines_ one could
possibly need.

One definitely usually wants a fixed _size_ (at least in my case): as
large as possible, but without covering up stuff that is not supposed
to be covered up (panels, whatever).

Sincerely,

Luc.

Re: frame size

[Luc Teirlinck]

>From my previous message:

   Sorry, I wrote this wrong.  I meant:

   But for the height, there is no fixed _number of lines_ one could
   possibly need.

Let me get this _finally_ right (sorry about needing three tries):

   But for the height, there is no fixed number of _text_ lines one
   could possibly need.

Sincerely,

Luc.

Re: frame size

[Richard Stallman]

    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?

It's even worse: on text-only terminals, the menu bar is included too.
These wrinkles are consequences of the implementation of those
features.

It would be a fair amount of work to change this.  I think it would be
most correct to exclude the various kinds of bars from the nominal
height.  But whether we include them or exclude them, either way we
would have to change many different functions and make sure they are
consistent.  Maybe after the next release we could do this, but let's
not do it now.