* Resizing windows after display-buffer
@ 2011-04-24 23:45 Chong Yidong
2011-04-25 0:09 ` Juanma Barranquero
0 siblings, 1 reply; 4+ messages in thread
From: Chong Yidong @ 2011-04-24 23:45 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Resizing windows after display-buffer
2011-04-24 23:45 Resizing windows after display-buffer Chong Yidong
@ 2011-04-25 0:09 ` Juanma Barranquero
2011-04-25 8:35 ` martin rudalics
0 siblings, 1 reply; 4+ messages in thread
From: Juanma Barranquero @ 2011-04-25 0:09 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Resizing windows after display-buffer
2011-04-25 0:09 ` Juanma Barranquero
@ 2011-04-25 8:35 ` martin rudalics
2011-04-25 13:00 ` Juanma Barranquero
0 siblings, 1 reply; 4+ messages in thread
From: martin rudalics @ 2011-04-25 8:35 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Chong Yidong, emacs-devel
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Resizing windows after display-buffer
2011-04-25 8:35 ` martin rudalics
@ 2011-04-25 13:00 ` Juanma Barranquero
0 siblings, 0 replies; 4+ messages in thread
From: Juanma Barranquero @ 2011-04-25 13:00 UTC (permalink / raw
To: martin rudalics; +Cc: Chong Yidong, emacs-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-04-25 13:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-24 23:45 Resizing windows after display-buffer Chong Yidong
2011-04-25 0:09 ` Juanma Barranquero
2011-04-25 8:35 ` martin rudalics
2011-04-25 13:00 ` Juanma Barranquero
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).