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: martin rudalics
Subject: bug#1806: dired-pop-to-buffer in wrong place
Date: Mon, 24 Sep 2012 11:40:29 +0200

> I tried to enable `temp-buffer-resize-mode', and with a large list of files
> it seems to ignore `window-combination-limit', i.e. the temporary window
> steals space from the window below.  A sample test case is:
> `M-x temp-buffer-resize-mode', in a Dired window `C-x 3 C-x 2 m m m ...'
> (mark 100 files), `!' (`dired-do-shell-command') steals space from the
> window below, and `C-g' doesn't restore the initial window configuration.
>
> Is this because `window-combination-limit' is not taken into account?
> I see that its default value is `temp-buffer-resize', the same unchanged
> value used in the test above.

No.  It's because resizing a window is allowed to steal space from _any_
other window on the frame.  That is, it will preferably steal space from
all other windows in the same combination (the upper window in our
case).  But if that is not sufficient, it can steal space from any other
window on the same frame.  We could make this optional but is it worth
the effort?

> I also tried a new action `display-buffer-at-bottom', and it doesn't
> seem quite right yet.  With the same configuration (`C-x 3 C-x 2'),
> and two marked files it displays a large almost empty window with just
> two lines.  `temp-buffer-resize-mode' helps to narrow it, but I still wonder
> why this window is not frame'e full-width?

I can add that if you want.  I suppose that your initial configuration
was that of >= 2 side-by-side windows at the bottom of the frame?

> I mean the idea was to display
> a list of files near the minibuffer prompt of the left side of the frame,
> but this list is displayed on the right side of the frame.

Aha.  So shall I split/reuse the left bottom window?  Or shall I split
the root window immediately?

>> `dired-pop-to-buffer' is no longer called and `dired-shrink-to-fit' is
>> no longer consulted.
>> If you really insist on handling dired's pop-up buffers separately,
>> I can do that by binding `temp-buffer-resize-mode' appropriately, but
>> I'd rather have a common solution for handling all temporary windows
>> in the same manner.
>
> There is nothing wrong when a package uses a local variable
> that changes the general behavior.  So `dired-mark-pop-up' could still
> call `dired-pop-to-buffer' that will bind `temp-buffer-resize-mode'
> according to the value of `dired-shrink-to-fit'.  This assumes that
> `dired-pop-to-buffer' is the right name for this functionality.
> Otherwise, it could be marked obsolete.

The question is whether we want one general setting to handle this.  I
intend to use this for `proced-with-processes-buffer' and vc-... buffers
too - adding a separate variable like `dired-shrink-to-fit' for each of
these seems some kind of proliferation.  Personally, I'd prefer to
declare `dired-shrink-to-fit' obsolete.

Note that I have added an option `temp-buffer-resize-regexps' which can
be used to turn off resizing in selected buffers.  I could invert the
meaning of this or do something different.  Any ideas?

martin





reply via email to

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