* bug#36859: Customizable fit-window-to-buffer
@ 2019-07-30 20:23 Juri Linkov
2019-07-31 9:12 ` martin rudalics
0 siblings, 1 reply; 14+ messages in thread
From: Juri Linkov @ 2019-07-30 20:23 UTC (permalink / raw)
To: 36859
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;
...
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#36859: Customizable fit-window-to-buffer
2019-07-30 20:23 bug#36859: Customizable fit-window-to-buffer Juri Linkov
@ 2019-07-31 9:12 ` martin rudalics
2019-07-31 20:57 ` Juri Linkov
0 siblings, 1 reply; 14+ messages in thread
From: martin rudalics @ 2019-07-31 9:12 UTC (permalink / raw)
To: Juri Linkov, 36859
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#36859: Customizable fit-window-to-buffer
2019-07-31 9:12 ` martin rudalics
@ 2019-07-31 20:57 ` Juri Linkov
2019-08-03 7:57 ` martin rudalics
0 siblings, 1 reply; 14+ messages in thread
From: Juri Linkov @ 2019-07-31 20:57 UTC (permalink / raw)
To: martin rudalics; +Cc: 36859
>> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#36859: Customizable fit-window-to-buffer
2019-07-31 20:57 ` Juri Linkov
@ 2019-08-03 7:57 ` martin rudalics
2019-08-03 21:16 ` Juri Linkov
0 siblings, 1 reply; 14+ messages in thread
From: martin rudalics @ 2019-08-03 7:57 UTC (permalink / raw)
To: Juri Linkov; +Cc: 36859
>> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#36859: Customizable fit-window-to-buffer
2019-08-03 7:57 ` martin rudalics
@ 2019-08-03 21:16 ` Juri Linkov
2019-08-04 8:00 ` martin rudalics
0 siblings, 1 reply; 14+ messages in thread
From: Juri Linkov @ 2019-08-03 21:16 UTC (permalink / raw)
To: martin rudalics; +Cc: 36859
>> 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'.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#36859: Customizable fit-window-to-buffer
2019-08-03 21:16 ` Juri Linkov
@ 2019-08-04 8:00 ` martin rudalics
2019-08-04 19:27 ` Juri Linkov
0 siblings, 1 reply; 14+ messages in thread
From: martin rudalics @ 2019-08-04 8:00 UTC (permalink / raw)
To: Juri Linkov; +Cc: 36859
>>> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#36859: Customizable fit-window-to-buffer
2019-08-04 8:00 ` martin rudalics
@ 2019-08-04 19:27 ` Juri Linkov
2019-08-05 9:23 ` martin rudalics
0 siblings, 1 reply; 14+ messages in thread
From: Juri Linkov @ 2019-08-04 19:27 UTC (permalink / raw)
To: martin rudalics; +Cc: 36859
>> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#36859: Customizable fit-window-to-buffer
2019-08-04 19:27 ` Juri Linkov
@ 2019-08-05 9:23 ` martin rudalics
2019-08-05 22:03 ` Juri Linkov
0 siblings, 1 reply; 14+ messages in thread
From: martin rudalics @ 2019-08-05 9:23 UTC (permalink / raw)
To: Juri Linkov; +Cc: 36859
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#36859: Customizable fit-window-to-buffer
2019-08-05 9:23 ` martin rudalics
@ 2019-08-05 22:03 ` Juri Linkov
2019-08-06 9:00 ` martin rudalics
0 siblings, 1 reply; 14+ messages in thread
From: Juri Linkov @ 2019-08-05 22:03 UTC (permalink / raw)
To: martin rudalics; +Cc: 36859
>> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#36859: Customizable fit-window-to-buffer
2019-08-05 22:03 ` Juri Linkov
@ 2019-08-06 9:00 ` martin rudalics
2019-08-06 22:16 ` Juri Linkov
0 siblings, 1 reply; 14+ messages in thread
From: martin rudalics @ 2019-08-06 9:00 UTC (permalink / raw)
To: Juri Linkov; +Cc: 36859
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#36859: Customizable fit-window-to-buffer
2019-08-06 9:00 ` martin rudalics
@ 2019-08-06 22:16 ` Juri Linkov
2019-08-07 22:01 ` Juri Linkov
0 siblings, 1 reply; 14+ messages in thread
From: Juri Linkov @ 2019-08-06 22:16 UTC (permalink / raw)
To: martin rudalics; +Cc: 36859
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#36859: Customizable fit-window-to-buffer
2019-08-06 22:16 ` Juri Linkov
@ 2019-08-07 22:01 ` Juri Linkov
2019-08-08 7:27 ` martin rudalics
0 siblings, 1 reply; 14+ messages in thread
From: Juri Linkov @ 2019-08-07 22:01 UTC (permalink / raw)
To: martin rudalics; +Cc: 36859
>> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#36859: Customizable fit-window-to-buffer
2019-08-07 22:01 ` Juri Linkov
@ 2019-08-08 7:27 ` martin rudalics
2019-08-08 21:39 ` Juri Linkov
0 siblings, 1 reply; 14+ messages in thread
From: martin rudalics @ 2019-08-08 7:27 UTC (permalink / raw)
To: Juri Linkov; +Cc: 36859
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#36859: Customizable fit-window-to-buffer
2019-08-08 7:27 ` martin rudalics
@ 2019-08-08 21:39 ` Juri Linkov
0 siblings, 0 replies; 14+ messages in thread
From: Juri Linkov @ 2019-08-08 21:39 UTC (permalink / raw)
To: martin rudalics; +Cc: 36859
>> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-08-08 21:39 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-07-30 20:23 bug#36859: Customizable fit-window-to-buffer Juri Linkov
2019-07-31 9:12 ` martin rudalics
2019-07-31 20:57 ` Juri Linkov
2019-08-03 7:57 ` martin rudalics
2019-08-03 21:16 ` Juri Linkov
2019-08-04 8:00 ` martin rudalics
2019-08-04 19:27 ` Juri Linkov
2019-08-05 9:23 ` martin rudalics
2019-08-05 22:03 ` Juri Linkov
2019-08-06 9:00 ` martin rudalics
2019-08-06 22:16 ` Juri Linkov
2019-08-07 22:01 ` Juri Linkov
2019-08-08 7:27 ` martin rudalics
2019-08-08 21:39 ` Juri Linkov
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).