* bug#11985: 24.1; fit-window-to-buffer does not grab whole frame
@ 2012-07-19 6:21 Roland Winkler
2012-07-19 10:42 ` martin rudalics
0 siblings, 1 reply; 7+ messages in thread
From: Roland Winkler @ 2012-07-19 6:21 UTC (permalink / raw)
To: 11985
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
^ permalink raw reply [flat|nested] 7+ messages in thread* bug#11985: 24.1; fit-window-to-buffer does not grab whole frame
2012-07-19 6:21 bug#11985: 24.1; fit-window-to-buffer does not grab whole frame Roland Winkler
@ 2012-07-19 10:42 ` martin rudalics
2012-07-19 16:14 ` martin rudalics
2012-07-19 16:32 ` Roland Winkler
0 siblings, 2 replies; 7+ messages in thread
From: martin rudalics @ 2012-07-19 10:42 UTC (permalink / raw)
To: Roland Winkler; +Cc: 11985
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#11985: 24.1; fit-window-to-buffer does not grab whole frame
2012-07-19 10:42 ` martin rudalics
@ 2012-07-19 16:14 ` martin rudalics
2012-07-19 16:32 ` Roland Winkler
1 sibling, 0 replies; 7+ messages in thread
From: martin rudalics @ 2012-07-19 16:14 UTC (permalink / raw)
To: Roland Winkler; +Cc: 11985
> > (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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#11985: 24.1; fit-window-to-buffer does not grab whole frame
2012-07-19 10:42 ` martin rudalics
2012-07-19 16:14 ` martin rudalics
@ 2012-07-19 16:32 ` Roland Winkler
2012-07-21 11:01 ` martin rudalics
1 sibling, 1 reply; 7+ messages in thread
From: Roland Winkler @ 2012-07-19 16:32 UTC (permalink / raw)
To: martin rudalics; +Cc: 11985
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#11985: 24.1; fit-window-to-buffer does not grab whole frame
2012-07-19 16:32 ` Roland Winkler
@ 2012-07-21 11:01 ` martin rudalics
2012-07-28 22:59 ` Roland Winkler
0 siblings, 1 reply; 7+ messages in thread
From: martin rudalics @ 2012-07-21 11:01 UTC (permalink / raw)
To: Roland Winkler; +Cc: 11985
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#11985: 24.1; fit-window-to-buffer does not grab whole frame
2012-07-21 11:01 ` martin rudalics
@ 2012-07-28 22:59 ` Roland Winkler
2012-10-06 12:56 ` martin rudalics
0 siblings, 1 reply; 7+ messages in thread
From: Roland Winkler @ 2012-07-28 22:59 UTC (permalink / raw)
To: martin rudalics; +Cc: 11985
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!
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#11985: 24.1; fit-window-to-buffer does not grab whole frame
2012-07-28 22:59 ` Roland Winkler
@ 2012-10-06 12:56 ` martin rudalics
0 siblings, 0 replies; 7+ messages in thread
From: martin rudalics @ 2012-10-06 12:56 UTC (permalink / raw)
To: 11985-done; +Cc: Roland Winkler
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-10-06 12:56 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-19 6:21 bug#11985: 24.1; fit-window-to-buffer does not grab whole frame Roland Winkler
2012-07-19 10:42 ` martin rudalics
2012-07-19 16:14 ` martin rudalics
2012-07-19 16:32 ` Roland Winkler
2012-07-21 11:01 ` martin rudalics
2012-07-28 22:59 ` Roland Winkler
2012-10-06 12:56 ` martin rudalics
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).