GNU bug report logs - #14233
24.3; Don't constrain frame size to character multiples

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: rgm <at> gnu.org, esabof <at> gmail.com, 14233 <at> debbugs.gnu.org
Subject: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Sun, 21 Apr 2013 18:03:22 +0300

> Date: Sun, 21 Apr 2013 11:26:10 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: rgm <at> gnu.org, esabof <at> gmail.com, 14233 <at> debbugs.gnu.org
> 
>  > a tool bar is just another
>  > window, so its size should be included in the frame's text height.
>  > What am I missing?  What is exactly that we are disagreeing about
>  > here?
> 
> OK.  But if the criterion to count something in the text height is that
> of being "just another window", we shouldn't include the display margins
> in the text width.

Display margins are certainly a part of window text.

>  > Which part of "width of FRAME, measured in
>  > characters" is unclear?
> 
> A frame, according to the Elisp manual, is a screen object that contains
> one or more Emacs windows.  When with emacs -Q I evaluate (frame-width)
> and (window-width) I get the values 80.  If I split the window into two
> side-by-side windows (frame-width) still evaluates to 80, but for both
> emanating windows (window-width) evaluates to 38.  Somehow 4 characters
> got lost in a black hole.  And bug#14222 demonstrates that Emacs itself
> sometimes doesn't understand its own nomenclature.

So you are saying that the doc strings leave a lot in the fog, I
guess.

Previous Next

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