unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: martin rudalics <rudalics@gmx.at>
Cc: Juanma Barranquero <lekktu@gmail.com>,
	Andreas Schwab <schwab@linux-m68k.org>,
	11810@debbugs.gnu.org
Subject: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window
Date: Sun, 01 Jul 2012 03:18:13 +0400	[thread overview]
Message-ID: <4FEF8935.9010508@yandex.ru> (raw)
In-Reply-To: <4FEEC259.7040308@gmx.at>

On 30.06.2012 13:09, martin rudalics wrote:
> `even-window-heights' is one of these options pertaining to the classic
> two windows one-above-the-other frame layout.  It should be redesigned
> to handle side-by-side windows and is largely obsolete anyway because
> you can now customize `window-combination-resize' instead.

How is it obsolete? As far as I can see, neither of the two possible 
values of `window-combination-resize' says "don't resize my existing 
windows until specifically asked".

>  > I don't think I've ever used `temp-buffer-resize-mode', but if it's a
>  > minor mode that a user has to enable explicitly, it should be fine if it
>  > overrides the value of `resize-windows-for-display'.
>  > Please note that `temp-buffer-resize-mode' already does the sane thing:
>  > it only resizes the window if the window is new and not reused.
>
> `temp-buffer-resize-mode' adds `resize-temp-buffer-window' to
> `temp-buffer-window-show-hook' so it resizes the window even when it's
> reused.  Or do I miss something?

Actually yes, I haven't tested it properly the last time.
It can shrink the window to make it fit the buffer, but it restores the 
window's size when it's done, which is the important thing.

>  > To answer you question in the last message:
>  >
>  >  >> !       (let ((resize-windows-for-display nil))
>  >  >> !  (pop-to-buffer (current-buffer)))
>  >  >
>  >  > Here you explicitly override the user option - is that intentional?
>  >
>  > It's intentional, because `vc-diff-internal' calls `pop-to-buffer'
>  > before the diff command returns its full output, so the window height
>  > adjustment happens in `vc-diff-finish' which runs after the process
>  > returns. So you might want to account for this usage.
>
> I don't recall the details but we always had a chicken-and-egg problem
> here: When you fill a buffer before displaying it you can't make its
> line breaks suit the window used for it.  When you display it first, you
> can't make the window suit the line breaks of the buffer.  And the
> number of line breaks determines the height of the region to display.

Do you mean auto-filling, as in, "inserting hard newlines"? I don't 
think diff-mode does that. It does pop a window immediately, but 
probably just because it would be weird to see a window pop up only 
after the diff command finishes (if that happens after some time has 
passed).

>  > Regarding "two similar approaches", I think just having an off by
>  > default `even-window-heights` variable and `temp-buffer-resize-mode' may
>  > satisfy more or less everyone, except there'd at least need to be a way
>  > to make shrinking asynchronous, as per above.
>
> Since I don't use `vc-diff' I can't really comment on how it should
> behave (I practically always use side-by-side windows for watching
> diffs).  Is anyone interested in the resizing behavior at all?  Couldn't
> we use the `quit-restore' window parameter to restore the original size
> of the window?

We probably could, if solving only this particular case is okay. As far 
as VC package goes, we'd need to do that in `vc-diff-internal' and in 
all (?) callers of `vc-log-internal-common'.

-- Dmitry





  parent reply	other threads:[~2012-06-30 23:18 UTC|newest]

Thread overview: 24+ 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 [this message]
2012-07-01  9:06         ` martin rudalics
     [not found]           ` <4FF05DC0.4080609@yandex.ru>
     [not found]             ` <4FF146F4.1080103@gmx.at>
2012-07-02 13:33               ` Dmitry Gutov
     [not found]               ` <4FF1A30F.4090806@yandex.ru>
2012-07-02 16:32                 ` martin rudalics
     [not found]                 ` <4FF1CD2C.5000704@gmx.at>
2012-07-02 20:39                   ` Dmitry Gutov
     [not found]                   ` <4FF206F5.4030101@yandex.ru>
2012-07-03  7:14                     ` martin rudalics
2012-07-03 12:48                       ` Dmitry Gutov
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

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FEF8935.9010508@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=11810@debbugs.gnu.org \
    --cc=lekktu@gmail.com \
    --cc=rudalics@gmx.at \
    --cc=schwab@linux-m68k.org \
    /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 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).