GNU bug report logs - #14795
height parameter inconsistent in new vs existing frames when tool-bar is enabled

Previous Next

Package: emacs;

Reported by: Juanma Barranquero <lekktu <at> gmail.com>

Date: Thu, 4 Jul 2013 22:54:02 UTC

Severity: wishlist

Merged with 25

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: 14795 <at> debbugs.gnu.org
Subject: Re: bug#14795: height parameter inconsistent in new vs existing
 frames when tool-bar is enabled
Date: Fri, 5 Jul 2013 01:11:35 +0200

Martin pointed out in emacs-devel that frame.c:x_figure_window_size()
includes the following comment:

  /* Add the tool-bar height to the initial frame height so that the
     user gets a text display area of the size he specified with -g or
     via .Xdefaults.  Later changes of the tool-bar height don't
     change the frame size.  This is done so that users can create
     tall Emacs frames without having to guess how tall the tool-bar
     will get.  */
  if (toolbar_p && FRAME_TOOL_BAR_LINES (f))

I remain unconvinced. That's mixing apples and oranges. If UI commands
(like -g) and UI settings (like X resources) should interpret the
frame height as meaning the client area, so be it. But then we should
decouple these from the `height' frame parameter, because it doesn't
really make sense to say that `height' means client area height when
creating a frame, but total frame height when modifying it.
This bug report was last modified 10 years and 140 days ago.

Previous Next

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