[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
Subject: bug#16013: 24.3.50; Rows in height is interpreted as pixels.
Date: Thu, 16 Jan 2014 11:03:32 +0100

Michael Welsh Duggan schrieb:
> Stefan Monnier <address@hidden> 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

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]