bug#16013: 24.3.50; Rows in height is interpreted as pixels.

[martin rudalics <rudalics@gmx.at>]

Michael Welsh Duggan schrieb:
 > Stefan Monnier <monnier@iro.umontreal.ca> writes:
 >
 >>> I know I am opening up a can of worms here, but I am going to argue that
 >>> `C-x SPC' be changed back to `gud-break'.
 >> Oddly enough there hasn't been the expected deluge of opinions.
 >
 > It surprises me, too.  My only guess is that people just don't use gdb
 > in emacs much, or they tend to use the mouse to set breakpoints.  (I
 > highly doubt people are using `C-x C-a C-b'.)  I guess I'll just have to
 > suggest rebinding it in gud-gdb-mode-hook to people who like it better
 > the way it was before.
 >
 > I know that the documentation updates are still a work in progress, but
 > please make sure current references to `C-x SPC' in the manual are
 > changed to `C-x C-a C-b' respectively.
 >

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