From: martin rudalics <rudalics@gmx.at>
To: Juri Linkov <juri@linkov.net>
Cc: 36859@debbugs.gnu.org
Subject: bug#36859: Customizable fit-window-to-buffer
Date: Sat, 3 Aug 2019 09:57:48 +0200 [thread overview]
Message-ID: <1d94d43d-45d8-c917-426f-f3ba8c0feabf@gmx.at> (raw)
In-Reply-To: <87sgqmq67t.fsf@mail.linkov.net>
>> 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
next prev parent reply other threads:[~2019-08-03 7:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1d94d43d-45d8-c917-426f-f3ba8c0feabf@gmx.at \
--to=rudalics@gmx.at \
--cc=36859@debbugs.gnu.org \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.