Resizing windows after display-buffer

Resizing windows after display-buffer

[Chong Yidong]

Not long ago, we discussed generalizing temp-buffer-resize-mode so that
it isn't just for Help buffers.  I propose doing this not with a minor
mode, but by adding a defcustom, display-buffer-fit-window-to-buffer.
See attached patch; window--display-buffer-2 (a subroutine of
display-buffer) will check this and call fit-window-to-buffer.

This should make temp-buffer-resize-mode unnecessary.  It will also
hopefully allow us to eliminate most calls to fit-window-to-buffer in
the Lisp tree (which are completely unregulated AFAICT), instead putting
the decision to fit displayed windows into one customizable location.

Thoughts/suggestions?


*** lisp/window.el	2011-04-19 13:44:55 +0000
--- lisp/window.el	2011-04-24 23:35:43 +0000
***************
*** 1038,1043 ****
--- 1038,1059 ----
        (raise-frame frame))
      window))
  
+ (defcustom display-buffer-fit-window-to-buffer nil
+   "Whether `display-buffer' should resize windows.
+ If the value is nil, no resizing is done.
+ 
+ If the value is non-nil, it should be a cons cell (MIN . MAX).
+ Any time `display-buffer' displays a buffer in another window, it
+ calls `fit-window-to-buffer', using MIN and MAX as the minimum
+ and maximum window heights.  Integers specify numbers of lines,
+ while floating point numbers specify fractions of the frame
+ height.
+ 
+ This variable has no effect when `display-buffer-function' is
+ non-nil, unless the specified function handles it explicitly."
+   :type '(choice (const nil) cons)
+   :group 'display)
+ 
  (defun window--display-buffer-2 (buffer window &optional dedicated)
    "Display BUFFER in WINDOW and make its frame visible.
  Set `window-dedicated-p' to DEDICATED if non-nil.
***************
*** 1046,1052 ****
      (set-window-buffer window buffer)
      (when dedicated
        (set-window-dedicated-p window dedicated))
!     (window--display-buffer-1 window)))
  
  (defvar display-buffer-mark-dedicated nil
    "If non-nil, `display-buffer' marks the windows it creates as dedicated.
--- 1062,1075 ----
      (set-window-buffer window buffer)
      (when dedicated
        (set-window-dedicated-p window dedicated))
!     (prog1 (window--display-buffer-1 window)
!       (when (consp display-buffer-fit-window-to-buffer)
! 	(let ((min (car display-buffer-fit-window-to-buffer))
! 	      (max (cdr display-buffer-fit-window-to-buffer))
! 	      (frame-height (frame-height (window-frame window))))
! 	  (if (floatp min) (setq min (round (* min frame-height))))
! 	  (if (floatp max) (setq max (round (* max frame-height))))
! 	  (fit-window-to-buffer window max min))))))
  
  (defvar display-buffer-mark-dedicated nil
    "If non-nil, `display-buffer' marks the windows it creates as dedicated.

Re: Resizing windows after display-buffer

[Juanma Barranquero]

On Mon, Apr 25, 2011 at 01:45, Chong Yidong <cyd@stupidchicken.com> wrote:

> Not long ago, we discussed generalizing temp-buffer-resize-mode so that
> it isn't just for Help buffers.  I propose doing this not with a minor
> mode, but by adding a defcustom, display-buffer-fit-window-to-buffer.

In my everyday use, I display the buffer I'm working on (code, a text
file, whatever) in a full window; the only time that the window is
split is for temporary or secondary uses; for example, help windows,
occur output, ielm, an inferior mode (python, lisp, etc.), re-builder,
bs-show, etc; and I make sure that the "secondary" buffer goes always
to the bottom window and that window is resized to fit the buffer or
have a height limit (typically about a third of the frame height). If
I switch to the bottom window and do something that would cause the
top window to display another buffer (multi-occur, for example, or
selecting a new buffer from bs-show), I *don't* want the top window to
be resized.

So, in my case, a setting that would make every display-buffer to try
to fit is much worse than a minor mode that I can call from whatever
mode hook I like.

    Juanma

Re: Resizing windows after display-buffer

[martin rudalics]

 > In my everyday use, I display the buffer I'm working on (code, a text
 > file, whatever) in a full window; the only time that the window is
 > split is for temporary or secondary uses; for example, help windows,
 > occur output, ielm, an inferior mode (python, lisp, etc.), re-builder,
 > bs-show, etc; and I make sure that the "secondary" buffer goes always
 > to the bottom window and that window is resized to fit the buffer or
 > have a height limit (typically about a third of the frame height).

I suppose the `fit-window-to-buffer' feature should probably depend on
the buffer name much like the options `same-window-buffer-names' or
`special-display-buffer-names' so a user can choose the set of buffers
where the windows should fit.  (I know that the variable can be made
buffer-local but the customization mechanism doesn't support that.)

 > If
 > I switch to the bottom window and do something that would cause the
 > top window to display another buffer (multi-occur, for example, or
 > selecting a new buffer from bs-show), I *don't* want the top window to
 > be resized.

This means the `fit-window-to-buffer' scheme should probably only apply
to new windows.  In the case you describe we have also to observe things
like `even-window-heights' whose interaction with `fit-window-to-buffer'
seems yet unresolved at the moment.  Likely `fit-window-to-buffer'
should prevail, but should we, for example, even sizes when both buffers
are to large to fit the window?

 > So, in my case, a setting that would make every display-buffer to try
 > to fit is much worse than a minor mode that I can call from whatever
 > mode hook I like.

We already have a defcustom like `dired-shrink-to-fit'.  Also note that
`temp-buffer-resize-mode' only applies to the `display-buffer' call
itself.  Thereafter, it does not have any effect - changing the size of
characters or the text of the buffer doesn't trigger resizing of the
window.  Hence calling this a mode seems a bit exaggerated.

So the question is why you think that activating a minor mode from a
mode hook is more convenient than setting an option from that hook.

martin

Re: Resizing windows after display-buffer

[Juanma Barranquero]

On Mon, Apr 25, 2011 at 10:35, martin rudalics <rudalics@gmx.at> wrote:

> I suppose the `fit-window-to-buffer' feature should probably depend on
> the buffer name much like the options `same-window-buffer-names' or
> `special-display-buffer-names' so a user can choose the set of buffers
> where the windows should fit.

Yes.

> This means the `fit-window-to-buffer' scheme should probably only apply
> to new windows.  In the case you describe we have also to observe things
> like `even-window-heights' whose interaction with `fit-window-to-buffer'
> seems yet unresolved at the moment.

In my case `even-window-heights' is set to nil quite soon in .emacs :-)

> Likely `fit-window-to-buffer'
> should prevail, but should we, for example, even sizes when both buffers
> are to large to fit the window?

I cannot answer that, because I haven't ever thought about
`even-window-heights' == t.

> We already have a defcustom like `dired-shrink-to-fit'.  Also note that
> `temp-buffer-resize-mode' only applies to the `display-buffer' call
> itself.  Thereafter, it does not have any effect - changing the size of
> characters or the text of the buffer doesn't trigger resizing of the
> window.  Hence calling this a mode seems a bit exaggerated.

In most cases, I'm not worried about not resizing the window after
creation; many modes do not require it (help,occur, ielm, inferior
interpreters), and for those that I want, I use an advice or a hook to
call fit-window-to-buffer. But it would be nice to have a true
minor-mode, of course.

> So the question is why you think that activating a minor mode from a
> mode hook is more convenient than setting an option from that hook.

If by "setting an option from that hook" you mean setting a local
variable in the buffer before it is displayed, then I'm OK.

    Juanma