Re: Please review: Small fix for window.c

[Stefan Monnier]

> Since any non-nil value for set-window-dedicated-p means window
> is dedicated, testing explicitly for Qt seems like a bug...


> *** window.c  28 Feb 2006 16:57:34 +0100      1.537
> --- window.c  08 Mar 2006 16:49:11 +0100      
> ***************
> *** 2009,2015 ****
>              `obj & 1' means consider only full-width windows.
>              `obj & 2' means consider also dedicated windows. */
>           if (((XINT (obj) & 1) && !WINDOW_FULL_WIDTH_P (w))
> !             || (!(XINT (obj) & 2) && EQ (w->dedicated, Qt))
>               /* Minibuffer windows are always ignored.  */
>               || MINI_WINDOW_P (w))
>             break;
> --- 2009,2015 ----
>              `obj & 1' means consider only full-width windows.
>              `obj & 2' means consider also dedicated windows. */
>           if (((XINT (obj) & 1) && !WINDOW_FULL_WIDTH_P (w))
> !             || (!(XINT (obj) & 2) && !NILP (w->dedicated))
>               /* Minibuffer windows are always ignored.  */
>               || MINI_WINDOW_P (w))
>             break;
> ***************
> *** 2064,2070 ****
>         case GET_LARGEST_WINDOW:
>           { /* nil `obj' means to ignore dedicated windows.  */
>             /* Ignore dedicated windows and minibuffers.  */
> !           if (MINI_WINDOW_P (w) || (NILP (obj) && EQ (w->dedicated, Qt)))
>               break;
  
>             if (NILP (best_window))
> --- 2064,2070 ----
>         case GET_LARGEST_WINDOW:
>           { /* nil `obj' means to ignore dedicated windows.  */
>             /* Ignore dedicated windows and minibuffers.  */
> !           if (MINI_WINDOW_P (w) || (NILP (obj) && !NILP (w->dedicated)))
>               break;
  
>             if (NILP (best_window))

I think this code comes from me.
I have a local hack here that extends the `dedicated' boolean to a 3-valued
element, such that a window can be either strongly dedicated (the current
notiong of dedication) or softly dedicated (a new concept).

A softly dedicated window is a window that's been created specifically to
display a particular buffer, but whose allegiance to this buffer may not
be eternal.  More specifically if the user decides to do switch-to-buffer,
no error will be signalled and instead the dedication flag will simply be
set to nil.  This way, when the buffer gets deleted the window also gets
deleted but only if the user hasn't used that window for some
other purpose in the mean time.

With this scheme, pop-to-buffer would typically set the dedicated flag of
windows it creates to `soft', so many/most windows start out as being
softly dedicated.

I hope I'll get enough time and motivation at some point to try and convince
Emacs's maintainers that this is a good idea and should be installed.

I've been using it for a few years now.  It was mostly developed out of
irritation at all the code that uses save-window-excursion around code that
uses display-buffer, without realizing the display-buffer may create a new
frame, in which case save-window-excursion is of no help.  Such code also
has the problem that if the wrapped code can live for a long time, the
restoration of the window-config of an hour ago may not be what the
user wants.

With soft-dedication, the use of set-window-configuration to try and undo
what display-buffer has done is replaced by a call to kill-buffer or
bury-buffer.


        Stefan