bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#1806: dired-pop-to-buffer in wrong place


From: Juri Linkov
Subject: bug#1806: dired-pop-to-buffer in wrong place
Date: Thu, 27 Sep 2012 22:24:30 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (x86_64-pc-linux-gnu)

>> and `set-window-start' like in the previously
>> used `dired-pop-to-buffer'.
>
> You never talked about `set-window-start' in the present context before.
> `with-temp-buffer-window' goes to `point-min' in the buffer it displays
> - is that not sufficient?

A month ago in revno:109790 you added two lines to `dired-pop-to-buffer':

  ;; See Bug#12281.
  (set-window-start nil (point-min))

so I wondered if this is still necessary after the recent redesign of
`dired-mark-pop-up' to not cause the same bug as reported in bug#12281.

>> The second regression is that the value `t'
>> of `window-combination-limit' is ignored,
>
> I don't understand again.  If `window-combination-limit' is t it remains
> t and is obeyed.  If it's 'temp-buffer or 'temp-buffer-resize it changes
> its value to t.

Some time ago setting `window-combination-limit' to t allowed
`fit-window-to-buffer' not to steal space from the lower window.
Only resizing at the cost of the upper window was allowed because it
has a common parent when `window-combination-limit' is t.  Now it seems
it has no effect and `fit-window-to-buffer' ignores the fact that
windows were split with `window-combination-limit' is t.

> `fit-window-to-buffer' steals space from the lower window if and only if
> the upper window is not large enough.  Otherwise it steals only from the
> upper window.  What do you expect me to do if the upper window is not
> large enough?  I do not have a solution for this because at the time I
> display the buffer I don't know how large the window is supposed to be.
> I can (1) do the calculations of `fit-window-to-buffer' before trying to
> split the window and (2) not split if the window won't fit and reuse the
> lower window instead.  But such a change is too invasive for the moment
> and wouldn't help anyway if the lower window is too small.

The problem is that it steals space when the upper window is large
and the *Marked files* buffer is large.  But it can't be completely
displayed anyway, so there is no need to resize the lower window.

When the upper window is small to split, there is no problem -
it just reuses the lower window.

> You simply ask too much here :-(

I'm not asking anything special.  I just believe that I found a bug in
`fit-window-to-buffer' and `window-combination-limit'.  Some time ago
`fit-window-to-buffer' obeyed the value t of `window-combination-limit',
and I don't understand why it's different now.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]