GNU bug report logs - #16013
24.3.50; Rows in height is interpreted as pixels.

Previous Next

Full log

Message #107 received at 16013 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: "16013 <at> debbugs.gnu.org" <16013 <at> debbugs.gnu.org>
Subject: Re: bug#16013: 24.3.50; Rows in height is interpreted as pixels.
Date: Thu, 16 Jan 2014 11:14:02 +0100

Sorry - my last mail contained unrelated text at the beginning.
Stripped now for better reading:

>> I frequently asked on this list what `frame-height' and especially the
>> "number of lines available for display" stands for, but never got an
>> answer I could understand.
>
>
> This has been inconsistent historically, i.e. Lucid/Motif/No toolkit counts differently than Gtk/NS.
> I think the Gtk count makes more sense.  If a user requests 50 lines he probably means 50 editable lines, not 47.  So I think we should not count tool bar or menu bar.
> The documentation says
> "The height of the frame contents, in characters."
> I don't think menu and tool bar is content.

I'm not sure what to do.  There's no problem for most elements of
`default-frame-alist' or when setting the default font.  The only real
offender is that of your init file - namely setting the default height.

A trivial scenario for Emacs 24.3 on Windows (I didn't try with that
version on Lucid/Motif but I suppose it's similar) is with emacs -Q:

(setq default-frame-alist '((height . 50)))

C-x 5 2

(set-frame-parameter nil 'height 50)

This changes the height of the new frame although it apparently is
already 50 lines high.  Such behavior constitutes a bug IMHO.  This
could be fixed but is certainly not trivial enough for inclusion in
24.4.

There are a few more arguments to count differently on Lucid/Motif/No
toolkit/Windows:

(1) When the window manager asks us to resize a frame, we do not
    subtract the toolbar height.  That is, the height of the toolbar is
    included in the frame's text height afterwards, defeating our
    illusion that it's counted separately.  This means an even less
    trivial fix than the one mentioned above.

(2) The real height of the toolbar is with tool_bar_height which might
    not fit the one we assume (in x_figure_window_size) anyway.  One
    more non-trivial fix since tool_bar_height is not available
    initially but only after the display engine handled it.  But the
    display engine wants the initial height of the frame so we have a
    chicken-and-egg problem here.

(3) Lucid/Motif/No toolkit/Windows can wrap the toolbar (something Gtk
    doesn't).  The display engine does this by stealing the necessary
    height from the editing area - that is, the root window - and
    autonomously updating the `tool-bar-lines' frame parameter.  This
    complicates subsequent frame resizing since we don't know a priori
    whether the toolbar will wrap again.

So while I agree with you that menu and tool bar should not be
considered content, I see no easy way to work around this assumption on
the systems in question.  Suggestions welcome.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.