bug#11985: 24.1; fit-window-to-buffer does not grab whole frame

bug#11985: 24.1; fit-window-to-buffer does not grab whole frame

[Roland Winkler]

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

bug#11985: 24.1; fit-window-to-buffer does not grab whole frame

[martin rudalics]

 > 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

bug#11985: 24.1; fit-window-to-buffer does not grab whole frame

[martin rudalics]

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

bug#11985: 24.1; fit-window-to-buffer does not grab whole frame

[Roland Winkler]

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.

bug#11985: 24.1; fit-window-to-buffer does not grab whole frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

 >> *** 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

[-- Attachment #2: fit-window-to-buffer.el --]
[-- Type: application/emacs-lisp, Size: 5928 bytes --]

bug#11985: 24.1; fit-window-to-buffer does not grab whole frame

[Roland Winkler]

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!

bug#11985: 24.1; fit-window-to-buffer does not grab whole frame

[martin rudalics]

 > 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