GNU bug report logs - #36859
Customizable fit-window-to-buffer

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 36859 in the body.
You can then email your comments to 36859 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: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Customizable fit-window-to-buffer
Date: Tue, 30 Jul 2019 23:23:03 +0300

It's a nice feature when fit-window-to-buffer resizes temporary windows
that go away after exiting the minibuffer.

OTOH, resizing permanent windows does more harm, because these windows
can be reused later for other buffers, but their size remains too narrow.

I'm not asking to change the default behavior, but it should be customizable.

Current examples of such behavior include:

- ‘C-h f’ (describe-function) diminishes the bottom vertically-split Help window;

- ‘C-x v l’ (vc-print-log) diminishes the log window if it contains a few entries;

- ‘C-x v =’ (vc-diff) diminishes the height of the diff window;

...

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>, 36859 <at> debbugs.gnu.org
Subject: Re: bug#36859: Customizable fit-window-to-buffer
Date: Wed, 31 Jul 2019 11:12:46 +0200

> It's a nice feature when fit-window-to-buffer resizes temporary windows
> that go away after exiting the minibuffer.
>
> OTOH, resizing permanent windows does more harm, because these windows
> can be reused later for other buffers, but their size remains too narrow.

What is a permanent window?  IIRC we only fit new windows or frames
that go away when quit and carefully try to not resize other windows
but the one used for splitting off the new window.  Old windows are
fit iff they did show the same buffer before and were created for that
buffer.  Such windows should, by concept, not be reused for showing
another buffer.

> I'm not asking to change the default behavior, but it should be customizable.

In what sense?

martin

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 36859 <at> debbugs.gnu.org
Subject: Re: bug#36859: Customizable fit-window-to-buffer
Date: Wed, 31 Jul 2019 23:57:14 +0300

>> It's a nice feature when fit-window-to-buffer resizes temporary windows
>> that go away after exiting the minibuffer.
>>
>> OTOH, resizing permanent windows does more harm, because these windows
>> can be reused later for other buffers, but their size remains too narrow.
>
> What is a permanent window?

A window that remains indefinitely after finishing the current command,
and where other buffers with different number of lines might appear.

                               IIRC we only fit new windows or frames
> that go away when quit and carefully try to not resize other windows
> but the one used for splitting off the new window.  Old windows are
> fit iff they did show the same buffer before and were created for that
> buffer.  Such windows should, by concept, not be reused for showing
> another buffer.

I see that the existing windows are resized with
'shrink-window-if-larger-than-buffer'.  So not only
'fit-window-to-buffer' is involved.

Two examples of 'shrink-window-if-larger-than-buffer':
- in vc-log-internal-common;
- in vc-diff-finish.

>> I'm not asking to change the default behavior, but it should be customizable.
>
> In what sense?

I hope it would be possible to specify a special action alist entry
in 'display-buffer-alist' , e.g.

  (window-height . no-fit-window)

to override

  (window-height . fit-window-to-buffer)

This requires that more commands should use this alist in their
'display-buffer' calls instead of directly calling
'shrink-window-if-larger-than-buffer'.

Do you think this is feasible?  If not, then maybe these commands
should provide post-display hooks such as e.g. 'proced-post-display-hook'
where 'fit-window-to-buffer' is added by default, but can be removed
by customization.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 36859 <at> debbugs.gnu.org
Subject: Re: bug#36859: Customizable fit-window-to-buffer
Date: Sat, 3 Aug 2019 09:57:48 +0200

>> What is a permanent window?
>
> A window that remains indefinitely after finishing the current command,
> and where other buffers with different number of lines might appear.

Then the "old windows" below ...

>                                 IIRC we only fit new windows or frames
>> that go away when quit and carefully try to not resize other windows
>> but the one used for splitting off the new window.  Old windows are
>> fit iff they did show the same buffer before and were created for that
>> buffer.  Such windows should, by concept, not be reused for showing
>> another buffer.

... are such permanent windows that should not get resized by
'display-buffer'.

> I see that the existing windows are resized with
> 'shrink-window-if-larger-than-buffer'.  So not only
> 'fit-window-to-buffer' is involved.
>
> Two examples of 'shrink-window-if-larger-than-buffer':
> - in vc-log-internal-common;

This one should shrink only if the window is either new or has a
'quit-restore' parameter that passes the

	    (and (eq (car quit-restore) 'same)
		 (eq (nth 1 quit-restore) 'window)))

test.  In either case, it will ignore any user supplied
'window-height' option.

> - in vc-diff-finish.

This should probably do a similar thing.

>>> I'm not asking to change the default behavior, but it should be customizable.
>>
>> In what sense?
>
> I hope it would be possible to specify a special action alist entry
> in 'display-buffer-alist' , e.g.
>
>    (window-height . no-fit-window)

Wouldn't just (window-height) suffice?

> to override
>
>    (window-height . fit-window-to-buffer)
>
> This requires that more commands should use this alist in their
> 'display-buffer' calls instead of directly calling
> 'shrink-window-if-larger-than-buffer'.

IIUC 'vc-log-internal-common' fills the buffer after popping to it so
I cannot see a way to simply accommodate that.

> Do you think this is feasible?  If not, then maybe these commands
> should provide post-display hooks such as e.g. 'proced-post-display-hook'
> where 'fit-window-to-buffer' is added by default, but can be removed
> by customization.

We could introduce a new ALIST argument, say 'pre-display-function'.
The function specified there would be called before running the body
of 'window--display-buffer'.  In the case at hand, that function would
fill the buffer so OT1H 'shrink-window-if-larger-than-buffer' would
know the real buffer size and OTOH a 'window-height' entry would allow
to override that.  I wouldn't know whether and how to suitably pass
any arguments to such a function, though.

martin

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 36859 <at> debbugs.gnu.org
Subject: Re: bug#36859: Customizable fit-window-to-buffer
Date: Sun, 04 Aug 2019 00:16:45 +0300

>> I hope it would be possible to specify a special action alist entry
>> in 'display-buffer-alist' , e.g.
>>
>>    (window-height . no-fit-window)
>
> Wouldn't just (window-height) suffice?

Maybe, I'm not sure if the case when window-height is missing in alist
can be distinguished from the case when window-height is nil.

>> Do you think this is feasible?  If not, then maybe these commands
>> should provide post-display hooks such as e.g. 'proced-post-display-hook'
>> where 'fit-window-to-buffer' is added by default, but can be removed
>> by customization.
>
> We could introduce a new ALIST argument, say 'pre-display-function'.
> The function specified there would be called before running the body
> of 'window--display-buffer'.  In the case at hand, that function would
> fill the buffer so OT1H 'shrink-window-if-larger-than-buffer' would
> know the real buffer size and OTOH a 'window-height' entry would allow
> to override that.  I wouldn't know whether and how to suitably pass
> any arguments to such a function, though.

Or maybe 'shrink-window-if-larger-than-buffer' could be added in the body
of another new ALIST argument 'post-display-function'.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 36859 <at> debbugs.gnu.org
Subject: Re: bug#36859: Customizable fit-window-to-buffer
Date: Sun, 4 Aug 2019 10:00:20 +0200

>>> I hope it would be possible to specify a special action alist entry
>>> in 'display-buffer-alist' , e.g.
>>>
>>>     (window-height . no-fit-window)
>>
>> Wouldn't just (window-height) suffice?
>
> Maybe, I'm not sure if the case when window-height is missing in alist
> can be distinguished from the case when window-height is nil.

The important aspect is that a (window-height) entry effectively
overrides a (window-height . fit-window-to-buffer) one.

> Or maybe 'shrink-window-if-larger-than-buffer' could be added in the body
> of another new ALIST argument 'post-display-function'.

Where would that 'post-display-function' be called?  This wouldn't be
any more in the scope of 'display-buffer'.

I'm still not convinced that this display buffer then fill buffer then
fit/shrink window according to buffer size metaphor makes any sense.
If we want to make the window size follow the buffer size, the buffer
should have been filled before being displayed.

martin

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 36859 <at> debbugs.gnu.org
Subject: Re: bug#36859: Customizable fit-window-to-buffer
Date: Sun, 04 Aug 2019 22:27:03 +0300

>> Or maybe 'shrink-window-if-larger-than-buffer' could be added in the body
>> of another new ALIST argument 'post-display-function'.
>
> Where would that 'post-display-function' be called?  This wouldn't be
> any more in the scope of 'display-buffer'.

Oops.

> I'm still not convinced that this display buffer then fill buffer then
> fit/shrink window according to buffer size metaphor makes any sense.
> If we want to make the window size follow the buffer size, the buffer
> should have been filled before being displayed.

In case of an asynchronous command like vc-log and vc-diff
postponing display-buffer might be undesirable because
their output might be useful to see while still incomplete.

OTOH, the current situation is not perfect either:
when an asynchronous command finishes, it unexpectedly
forces the window resizing.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 36859 <at> debbugs.gnu.org
Subject: Re: bug#36859: Customizable fit-window-to-buffer
Date: Mon, 5 Aug 2019 11:23:32 +0200

> In case of an asynchronous command like vc-log and vc-diff
> postponing display-buffer might be undesirable because
> their output might be useful to see while still incomplete.

Agreed.

> OTOH, the current situation is not perfect either:
> when an asynchronous command finishes, it unexpectedly
> forces the window resizing.

Then as a rule let's avoid such resizing.  I doubt that anyone really
wanted it.  It's merely the fact that functions like
`shrink-window-if-larger-than-buffer' were written that people
started to use them wherever applicable ...

martin

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 36859 <at> debbugs.gnu.org
Subject: Re: bug#36859: Customizable fit-window-to-buffer
Date: Tue, 06 Aug 2019 01:03:02 +0300

>> OTOH, the current situation is not perfect either:
>> when an asynchronous command finishes, it unexpectedly
>> forces the window resizing.
>
> Then as a rule let's avoid such resizing.  I doubt that anyone really
> wanted it.  It's merely the fact that functions like
> `shrink-window-if-larger-than-buffer' were written that people
> started to use them wherever applicable ...

Before disabling window shrinking we need to support its
customization, so shrinking could be enabled easily
by anyone who wants it.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 36859 <at> debbugs.gnu.org
Subject: Re: bug#36859: Customizable fit-window-to-buffer
Date: Tue, 6 Aug 2019 11:00:25 +0200

> Before disabling window shrinking we need to support its
> customization, so shrinking could be enabled easily
> by anyone who wants it.

Doing this via 'display-buffer' is hardly feasible: We would have to
provide some magic that adds the (window-height) and (window-width)
functionalities to the sentinel of the process.  vc.el uses an advice
for that and I'm afraid that's one step too far for `display-buffer'.

The only practicable solution IMHO is to provide a plain
'vc-adjust-window-size-function' option defaulting to
'shrink-window-if-larger-than-buffer' and allowing 'ignore' and
'fit-window-to-buffer' as alternatives.

martin

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 36859 <at> debbugs.gnu.org
Subject: Re: bug#36859: Customizable fit-window-to-buffer
Date: Wed, 07 Aug 2019 01:16:01 +0300

> The only practicable solution IMHO is to provide a plain
> 'vc-adjust-window-size-function' option defaulting to
> 'shrink-window-if-larger-than-buffer' and allowing 'ignore' and
> 'fit-window-to-buffer' as alternatives.

This looks like hooks.  I too like hooks, I don't understand
why vc uses such inconvenient macros as vc-run-delayed
instead of more flexible hooks.  Window management could use
hooks more often, e.g. to delay setting window-start/window-point
to later times when the buffer is ready, etc.

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 36859 <at> debbugs.gnu.org
Subject: Re: bug#36859: Customizable fit-window-to-buffer
Date: Thu, 08 Aug 2019 01:01:10 +0300

>> The only practicable solution IMHO is to provide a plain
>> 'vc-adjust-window-size-function' option defaulting to
>> 'shrink-window-if-larger-than-buffer' and allowing 'ignore' and
>> 'fit-window-to-buffer' as alternatives.
>
> This looks like hooks.  I too like hooks, I don't understand
> why vc uses such inconvenient macros as vc-run-delayed
> instead of more flexible hooks.  Window management could use
> hooks more often, e.g. to delay setting window-start/window-point
> to later times when the buffer is ready, etc.

I see there is a hook already in vc: 'vc-post-command-functions'.
But it's unclear how to use it to call 'shrink-window-if-larger-than-buffer'
from the hook only on vc-log and vc-diff commands.

Maybe vc-log-internal-common and vc-diff-internal could provide new hooks,
e.g. vc-log-post-command-functions and vc-diff-post-command-functions.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 36859 <at> debbugs.gnu.org
Subject: Re: bug#36859: Customizable fit-window-to-buffer
Date: Thu, 8 Aug 2019 09:27:12 +0200

> I see there is a hook already in vc: 'vc-post-command-functions'.
> But it's unclear how to use it to call 'shrink-window-if-larger-than-buffer'
> from the hook only on vc-log and vc-diff commands.
>
> Maybe vc-log-internal-common and vc-diff-internal could provide new hooks,
> e.g. vc-log-post-command-functions and vc-diff-post-command-functions.

What's the scope of a command?  When it invokes an asynchonous process
does it end when that process starts or when it finishes?  Since I
think that it's the former (how else could we then distiniguish "this"
command from the "last" command), the idiom "post-command" appears
inappropriate here.

martin

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 36859 <at> debbugs.gnu.org
Subject: Re: bug#36859: Customizable fit-window-to-buffer
Date: Fri, 09 Aug 2019 00:39:20 +0300

>> I see there is a hook already in vc: 'vc-post-command-functions'.
>> But it's unclear how to use it to call 'shrink-window-if-larger-than-buffer'
>> from the hook only on vc-log and vc-diff commands.
>>
>> Maybe vc-log-internal-common and vc-diff-internal could provide new hooks,
>> e.g. vc-log-post-command-functions and vc-diff-post-command-functions.
>
> What's the scope of a command?  When it invokes an asynchonous process
> does it end when that process starts or when it finishes?  Since I
> think that it's the former (how else could we then distiniguish "this"
> command from the "last" command), the idiom "post-command" appears
> inappropriate here.

Indeed vc-post-command-functions is a misnomer, and should have been
called vc-post-process-functions.

Previous Next

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