* Please review: Small fix for window.c
@ 2006-03-08 15:52 Kim F. Storm
2006-03-08 16:11 ` Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: Kim F. Storm @ 2006-03-08 15:52 UTC (permalink / raw)
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))
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Please review: Small fix for window.c
2006-03-08 15:52 Please review: Small fix for window.c Kim F. Storm
@ 2006-03-08 16:11 ` Stefan Monnier
2006-03-08 20:23 ` Kim F. Storm
2006-03-09 17:14 ` Richard Stallman
0 siblings, 2 replies; 6+ messages in thread
From: Stefan Monnier @ 2006-03-08 16:11 UTC (permalink / raw)
Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Please review: Small fix for window.c
2006-03-08 16:11 ` Stefan Monnier
@ 2006-03-08 20:23 ` Kim F. Storm
2006-03-09 4:48 ` Miles Bader
2006-03-09 17:14 ` Richard Stallman
1 sibling, 1 reply; 6+ messages in thread
From: Kim F. Storm @ 2006-03-08 20:23 UTC (permalink / raw)
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Please review: Small fix for window.c
2006-03-08 16:11 ` Stefan Monnier
2006-03-08 20:23 ` Kim F. Storm
@ 2006-03-09 17:14 ` Richard Stallman
1 sibling, 0 replies; 6+ messages in thread
From: Richard Stallman @ 2006-03-09 17:14 UTC (permalink / raw)
Cc: emacs-devel, storm
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Please review: Small fix for window.c
@ 2006-03-09 7:52 klaus.berndl
0 siblings, 0 replies; 6+ messages in thread
From: klaus.berndl @ 2006-03-09 7:52 UTC (permalink / raw)
Cc: emacs-devel
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!
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-03-09 17:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-08 15:52 Please review: Small fix for window.c Kim F. Storm
2006-03-08 16:11 ` Stefan Monnier
2006-03-08 20:23 ` Kim F. Storm
2006-03-09 4:48 ` Miles Bader
2006-03-09 17:14 ` Richard Stallman
-- strict thread matches above, loose matches on Subject: below --
2006-03-09 7:52 klaus.berndl
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).