all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: Andreas Schwab <schwab@linux-m68k.org>, 11810@debbugs.gnu.org
Subject: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window
Date: Sat, 30 Jun 2012 11:09:45 +0200	[thread overview]
Message-ID: <4FEEC259.7040308@gmx.at> (raw)
In-Reply-To: <4FEE2EA5.5060905@yandex.ru>

 > I think renaming and reusing `even-window-heights' is a good thing to
 > do. I'd even suggest changing the default value, because, as you can
 > see, virtually nobody among users knows about this variable:
 >
 > http://stackoverflow.com/questions/4716855/how-can-i-prevent-emacs-resizing-my-windows
 >
 >
 > (Usually folks at SO give fairly comprehensive answers).
 > And personally, I'd have been very happy to know about it about 1-2
 > years ago, before `pop-to-window' behavior strongly conditioned me
 > against manually resizing windows.

`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.

 > 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?

 > 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.

 > 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?

martin





  reply	other threads:[~2012-06-30  9:09 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 [this message]
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 13:33               ` Dmitry Gutov
2012-07-02 16:32                 ` martin rudalics
2012-07-02 20:39                   ` Dmitry Gutov
2012-07-02 20:39                   ` Dmitry Gutov
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
2012-07-02 16:32                 ` martin rudalics

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=4FEEC259.7040308@gmx.at \
    --to=rudalics@gmx.at \
    --cc=11810@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    --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 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.