GNU bug report logs - #11985
24.1; fit-window-to-buffer does not grab whole frame

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Roland Winkler <winkler <at> gnu.org>
Cc: 11985 <at> debbugs.gnu.org
Subject: bug#11985: 24.1; fit-window-to-buffer does not grab whole frame
Date: Thu, 19 Jul 2012 18:14:02 +0200

>  > (3) The relation between the new arg OVERRIDE (not present in Emacs
>  >     23.1) and window-min-height and window-min-width is not clear to
>  >     me.
>
> Neither to me.

With OVERRIDE nil, `fit-window-to-buffer' behaves as in 23.1 which means
that WINDOW can't get smaller than `window-min-height'.  This was an
elementary restriction on Emacs 23.1 because otherwise WINDOW could have
been deleted during the next resize operation.  With Emacs 24.1 windows
are no more deleted automatically, which means that any window can get
as small as `window-safe-min-height' without risking of being deleted.

Hence if you want WINDOW to get smaller than `window-min-height' during
a `fit-window-to-buffer' operation, you can set OVERRIDE non-nil and
`window-min-height' is not respected for WINDOW by this operation (which
makes sense if you want to display just one or two lines of text in that
window).

Note that an application cannot safely bind `window-min-height' to a
smaller value to accomplish the same effect since `window-min-height'
affects all windows.  If `fit-window-to-buffer' enlarged WINDOW with
`window-min-height' bound to 1, this could cause an unrelated window
getting shrunk to one line (in general, an application cannot tell a
priori whether `fit-window-to-buffer' will actually shrink or enlarge
WINDOW).

In any case, the doc-string sucks in explaining what I wrote above.  If,
based on my explanations, anyone could come up with a better doc-string,
I'd be grateful.

martin

Previous Next

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