Please review: Small fix for window.c

Please review: Small fix for window.c

[Kim F. Storm]

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

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

Re: Please review: Small fix for window.c

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> 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 think it sounds like an excellent idea!

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

Nice!


I was thinking about another kind of "hard" dedication -- where a window
cannot be deleted unless you kill the associated buffer.  It seems useful
for stuff like ECB which don't want _anything_ to mess with its windows.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Please review: Small fix for window.c

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> I was thinking about another kind of "hard" dedication -- where a window
> cannot be deleted unless you kill the associated buffer. 

Man, Emacs is getting kinkier all the time...

-miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

RE: Please review: Small fix for window.c

[klaus.berndl]

Kim F. Storm wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>> 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 think it sounds like an excellent idea!

I second this...

> 
>> 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.
> 
> Nice!
> 
> 
> I was thinking about another kind of "hard" dedication -- where a
> window cannot be deleted unless you kill the associated buffer.  It
> seems useful for stuff like ECB which don't want _anything_ to mess
> with its windows.

Yes, sounds like an excellent idea, different levels of dedication could
solve the problems of tools like ECB and would allow to throw away a lot
of advices currently necessary for ECB!

Re: Please review: Small fix for window.c

[Richard Stallman]

    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.

It sounds like a good idea.