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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11985 in the body.
You can then email your comments to 11985 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Roland Winkler" <winkler <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.1; fit-window-to-buffer does not grab whole frame
Date: Thu, 19 Jul 2012 01:21:26 -0500

Start emacs -Q. Visit a file larger than the current frame.
Split the frame, Display other stuff in second window.
Select the window with the large file.
Eval

  (fit-window-to-buffer (selected-window))

Expected result: The window should grab the whole frame. From the
docstring of fit-window-to-buffer

  Optional argument MAX-HEIGHT specifies the maximum height of
  WINDOW and defaults to the height of WINDOW's frame.

Remarks: 
(1) This works as documented with GNU Emacs 23.1.
    -- Of course, the old behavior was counterintuitive in the sense
    that the name of fit-window-to-buffer refers to windows, not to
    frames. But an incompatible change in behavior should be
    documented.

(2) I suggest that the elisp manual should also mention the default
    values of MAX-HEIGHT and MIN-HEIGHT (as in the docstring).

(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. If MIN-HEIGHT is non-nil, shouldn't this already ignore
    window-min-height? Also, if OVERRIDE is nil, what is the
    relevance of window-min-width? I expect fit-window-to-buffer is
    supposed to obey window-min-width. But it would clarify things
    if this was spelled out.


In GNU Emacs 24.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2012-06-10 on regnitz
Windowing system distributor `The X.Org Foundation', version 11.0.10706000

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

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

> Start emacs -Q. Visit a file larger than the current frame.
> Split the frame, Display other stuff in second window.
> Select the window with the large file.
> Eval
>
>   (fit-window-to-buffer (selected-window))
>
> Expected result: The window should grab the whole frame. From the
> docstring of fit-window-to-buffer
>
>   Optional argument MAX-HEIGHT specifies the maximum height of
>   WINDOW and defaults to the height of WINDOW's frame.
>
> Remarks:
> (1) This works as documented with GNU Emacs 23.1.
>     -- Of course, the old behavior was counterintuitive in the sense
>     that the name of fit-window-to-buffer refers to windows, not to
>     frames. But an incompatible change in behavior should be
>     documented.

From NEWS:

*** Window resizing functions.
A new standard function for resizing windows called `window-resize' has
been introduced.  This and all other functions for resizing windows no
longer delete any windows when they become too small.

> (2) I suggest that the elisp manual should also mention the default
>     values of MAX-HEIGHT and MIN-HEIGHT (as in the docstring).

OK.

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

> If MIN-HEIGHT is non-nil, shouldn't this already ignore
>     window-min-height?

Sounds reasonable, indeed.

> Also, if OVERRIDE is nil, what is the
>     relevance of window-min-width? I expect fit-window-to-buffer is
>     supposed to obey window-min-width. But it would clarify things
>     if this was spelled out.

`window-min-width' shouldn't be mentioned at all.

I'll look into this.  If you have any ideas what this function should
_do_ better, please tell me.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Roland Winkler <winkler <at> gnu.org>
Cc: 11985 <at> debbugs.gnu.org
Subject: Re: 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

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

From: "Roland Winkler" <winkler <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 11985 <at> debbugs.gnu.org
Subject: Re: bug#11985: 24.1; fit-window-to-buffer does not grab whole frame
Date: Thu, 19 Jul 2012 11:32:26 -0500

On Thu Jul 19 2012 martin rudalics wrote:
>  From NEWS:
> 
> *** Window resizing functions.
> A new standard function for resizing windows called `window-resize' has
> been introduced.  This and all other functions for resizing windows no
> longer delete any windows when they become too small.

This is a bit buried if one simply searches for fit-window-to-buffere.

> I'll look into this.  If you have any ideas what this function should
> _do_ better, please tell me.

I got into this when I discovered that with Emacs 24.1
Electric-pop-up-window does not behave anymore as expected. It uses
fit-window-to-buffer for possibly grabbing the whole frame. In the
context of what Electric-pop-up-window wants to achieve this is a
reasonable and documented behavior.
Possibly there is more code that relies on the old behavior.

But I agree that it is probably cleaner if functions such as
Electric-pop-up-window implement this old aspect of
fit-window-to-buffer in some other way.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Roland Winkler <winkler <at> gnu.org>
Cc: 11985 <at> debbugs.gnu.org
Subject: Re: bug#11985: 24.1; fit-window-to-buffer does not grab whole frame
Date: Sat, 21 Jul 2012 13:01:20 +0200

[Message part 1 (text/plain, inline)]

>> *** Window resizing functions.
>> A new standard function for resizing windows called `window-resize' has
>> been introduced.  This and all other functions for resizing windows no
>> longer delete any windows when they become too small.
>
> This is a bit buried if one simply searches for fit-window-to-buffer e.

It was a very invasive change mainly affecting `enlarge-window' which
was called by the old `fit-window-to-buffer' (note that calling
`fit-window-to-buffer' with Emacs 23.1 could delete WINDOW itself).  I
didn't go through all callers of enlarge-/shrink-buffer to check whether
they should be mentioned to.

> I got into this when I discovered that with Emacs 24.1
> Electric-pop-up-window does not behave anymore as expected. It uses
> fit-window-to-buffer for possibly grabbing the whole frame. In the
> context of what Electric-pop-up-window wants to achieve this is a
> reasonable and documented behavior.
> Possibly there is more code that relies on the old behavior.
>
> But I agree that it is probably cleaner if functions such as
> Electric-pop-up-window implement this old aspect of
> fit-window-to-buffer in some other way.

I have no strong opinion on this and never managed to understand how the
old window resize routines worked.  What about the version I attached?
If necessary, I can get more aggressive ;-)

martin

[fit-window-to-buffer.el (application/emacs-lisp, inline)]

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

From: "Roland Winkler" <winkler <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 11985 <at> debbugs.gnu.org
Subject: Re: bug#11985: 24.1; fit-window-to-buffer does not grab whole frame
Date: Sat, 28 Jul 2012 17:59:02 -0500

On Sat Jul 21 2012 martin rudalics wrote:
> I have no strong opinion on this and never managed to understand
> how the old window resize routines worked. What about the version
> I attached? If necessary, I can get more aggressive ;-)

I am sorry, this goes much beyond what I feel confident to comment on.

I got into this when working on BBDB. This uses
Electric-pop-up-window. With Emacs 24.1 this function does not
behave anymore as expected.  Electric-pop-up-window
calls fit-window-to-buffer which calls enlarge-window.

In the meanwhile I learnt from Stefan (bug#11983) that it's probably
best for BBDB (and possibly other packages too) to get rid of all
the Electric-* stuff. So I have not much an opinion with respect to 
fit-window-to-buffer, and there is yet less I could say about
enlarge-window.

Anyway, thanks for looking into this!

Message #25 received at 11985-done <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: 11985-done <at> debbugs.gnu.org
Cc: Roland Winkler <winkler <at> gnu.org>
Subject: Re: bug#11985: 24.1; fit-window-to-buffer does not grab whole frame
Date: Sat, 06 Oct 2012 14:56:25 +0200

> In the meanwhile I learnt from Stefan (bug#11983) that it's probably
> best for BBDB (and possibly other packages too) to get rid of all
> the Electric-* stuff. So I have not much an opinion with respect to
> fit-window-to-buffer, and there is yet less I could say about
> enlarge-window.

OK.   Closing this bug.

martin

Previous Next

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