From: Dmitry Gutov <dgutov@yandex.ru>
To: martin rudalics <rudalics@gmx.at>
Cc: 11810@debbugs.gnu.org
Subject: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window
Date: Tue, 03 Jul 2012 16:48:13 +0400 [thread overview]
Message-ID: <4FF2EA0D.9030006@yandex.ru> (raw)
In-Reply-To: <4FF29BE7.2030006@gmx.at>
On 03.07.2012 11:14, martin rudalics wrote:
> >> >> (2) When `temp-buffer-resize-mode' is nil and the window size has
> >> >> changed, the change was probably due to some manual
> intervention
> >> >> probably needed to see more of a buffer originally present
> >> and it
> >> >> seems better to leave that change alone.
> >>
> >> ... in this case we can be sure that the user changed the size so we
> >> probably should leave it alone.
> >
> > That depends on the definition of "the user". In our case, *I* didn't
> > explicitly resize the window, `vc-diff' did.
>
> Because of `even-window-heights'? That's something I obviously forgot
Because of `shrink-window-if-larger-than-buffer'.
`even-window-heights' could have contributed in another case, if my
windows were not of equal height already.
> to handle when quitting a window. Maybe the best solution is to set the
> 3rd element of the quit-restore parameter iff either
>
> (1) `temp-buffer-resize-mode' is non-nil, or
Maybe just when `fit-window-to-buffer' is called? That would account for
`shrink-window-if-larger-than-buffer', too.
> (2) `window--even-window-heights' actually did resize the window
>
> and don't do the `temp-buffer-resize-mode' check in `quit-window'.
>
> > How about clearing (or changing) the 'quit-window parameter in each
> > command when we're sure that the user won't want to have the size
> > restored afterwards?
> > There would be a set of "user-facing" functions that would do that.
>
> `adjust-window-trailing-edge' would be an obvious candidate. But which
> window's parameter would you clear? Both?
What's the second one? Please keep in mind that I don't know the
window.el codebase, I'm just reading the code along the discussion.
> > How will the temp-buffer-resize-mode null check help in this case?
> > It's a global minor mode, so it's either t in all buffers, or nil in all
> > of them.
>
> That's why I would have set `temp-buffer-resize-mode' buffer-locally to
> t. But it's ugly.
If `temp-buffer-resize-mode' were on, that wouldn't have made a
difference, would it?
You'd have to locally set `temp-buffer-resize-mode' to nil in all cases
when you don't want the window size to be restored afterwards, which is
the same amount of work as clearing 'quit-window parameter.
> >> I don't know. I think a vc-diff buffer should be considerded a
> >> temporary buffer, subject to `temp-buffer-resize-mode'. Ideally,
> >> windows of non-temporary buffers are never shrunk automatically.
> >
> > Would a window that displayed a normal buffer previously but which now
> > is displaying a temporary buffer be considered a "window of
> > non-temporary buffer"?
>
> Only after it displays the normal buffer again. Why did you ask?
Because that's what at issue here. I think the main two cases of
automatic shrinking are:
1) "temp buffer" in a window that was created for it,
2) "temp buffer" in a reused window,
and 2) is the reason I filed this bug.
next prev parent reply other threads:[~2012-07-03 12:48 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-28 19:22 bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window Dmitry Gutov
2012-06-28 22:32 ` Andreas Schwab
2012-06-28 22:45 ` Dmitry Gutov
2012-06-29 7:12 ` Andreas Schwab
2012-06-29 7:12 ` martin rudalics
2012-06-29 22:39 ` Dmitry Gutov
2012-06-30 9:09 ` martin rudalics
2012-06-30 21:34 ` Juanma Barranquero
2012-07-01 9:06 ` martin rudalics
2012-06-30 23:18 ` Dmitry Gutov
2012-07-01 9:06 ` martin rudalics
[not found] ` <4FF05DC0.4080609@yandex.ru>
2012-07-02 7:00 ` martin rudalics
2012-07-02 13:33 ` Dmitry Gutov
2012-07-02 16:32 ` martin rudalics
2012-07-02 20:39 ` Dmitry Gutov
2012-07-03 7:14 ` martin rudalics
2012-07-03 12:48 ` Dmitry Gutov [this message]
2012-07-03 16:40 ` martin rudalics
2012-07-03 18:56 ` Dmitry Gutov
2012-07-04 9:18 ` martin rudalics
2012-07-04 16:12 ` Dmitry Gutov
2012-07-05 9:53 ` martin rudalics
2012-07-05 23:19 ` Dmitry Gutov
2012-07-06 6:36 ` martin rudalics
2012-07-06 12:25 ` Dmitry Gutov
2012-07-02 20:39 ` Dmitry Gutov
2012-07-02 16:32 ` martin rudalics
2012-07-02 13:33 ` Dmitry Gutov
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=4FF2EA0D.9030006@yandex.ru \
--to=dgutov@yandex.ru \
--cc=11810@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/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.