bug#32825: 27.0.50; Deterministic window management

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

0. emacs -Q

1. create 3 windows, e.g.:
   C-x 3
   C-x 2

2. type a random letter, e.g. 'z'

3. eval it with 'C-x C-e'
   the *Backtrace* buffer with an error appears in some window,
   quit it with 'q'

4. eval again exactly with the same key 'C-x C-e',
   the *Backtrace* buffer appears in another window,
   not where it appeared the previous time.

What is expected: window management should be more deterministic in the
sense that the result of the window operation should be expected beforehand,
not popping windows in random places.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > 0. emacs -Q
 >
 > 1. create 3 windows, e.g.:
 >     C-x 3
 >     C-x 2
 >
 > 2. type a random letter, e.g. 'z'
 >
 > 3. eval it with 'C-x C-e'
 >     the *Backtrace* buffer with an error appears in some window,
 >     quit it with 'q'
 >
 > 4. eval again exactly with the same key 'C-x C-e',
 >     the *Backtrace* buffer appears in another window,
 >     not where it appeared the previous time.
 >
 > What is expected: window management should be more deterministic in the
 > sense that the result of the window operation should be expected beforehand,
 > not popping windows in random places.

We have 'display-buffer-in-previous-window' for that purpose and the
function responsible for displaying the *Backtrace* buffer should use
it.

martin

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> We have 'display-buffer-in-previous-window' for that purpose and the
> function responsible for displaying the *Backtrace* buffer should use
> it.

Actually, it already does, but `display-buffer-in-previous-window'
doesn't behave as expected.  Seems it fails.  Maybe the recursive edit
the debugger uses interferes, dunno.


Michael.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > Actually, it already does, but `display-buffer-in-previous-window'
 > doesn't behave as expected.  Seems it fails.  Maybe the recursive edit
 > the debugger uses interferes, dunno.

No.  It's the default setting of 'debugger-bury-or-kill'.  With
'append' it does reuse the previous window.  With the default 'bury'
the buffer is not added to the window's list of previous buffers.  We
can set the default to 'append' but then the *backtrace* buffer may
eventually show up when invoking 'previous-buffer' which can be a
nuisance, sometimes.  I leave the choice to you and Juri.

martin

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> No.  It's the default setting of 'debugger-bury-or-kill'.

Ah, ok.

I still wonder why the window selection doesn't seem to be
deterministic, though.  Maybe the answer could help us to find a
solution without messing with debugger-bury-or-kill.

> I leave the choice to you and Juri.

I don't know much about the backgrounds, I just had the time to debug a
bit ;-)  So I leave the choice to Juri.


Michael.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > I still wonder why the window selection doesn't seem to be
 > deterministic, though.  Maybe the answer could help us to find a
 > solution without messing with debugger-bury-or-kill.

That's easy to explain.  In both calls Emacs shows *Backtrace* in the
least recently used window.  But since it also selects that window,
the window used in the first call is no more the least recently used
one in the second call.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> I still wonder why the window selection doesn't seem to be
> deterministic, though.  Maybe the answer could help us to find a
> solution without messing with debugger-bury-or-kill.

I wish the window selection to be more deterministic too.
Maybe instead of selecting the least recently used window
we should have a choice what window to select.

>> I leave the choice to you and Juri.
>
> I don't know much about the backgrounds, I just had the time to debug a
> bit ;-)  So I leave the choice to Juri.

I have no choice :-)

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > I wish the window selection to be more deterministic too.
 > Maybe instead of selecting the least recently used window
 > we should have a choice what window to select.

With an appropriate alist entry.  BTW the two 'get-buffer-window'
disjuncts below are leftovers from the old code IIRC.  IMO we should
drop them in the course of such a change.

	  (or (get-lru-window frame nil not-this-window)
	      (let ((window (get-buffer-window buffer 'visible)))
		(unless (and not-this-window
			     (eq window (selected-window)))
		  window))
	      (get-largest-window 'visible nil not-this-window)
	      (let ((window (get-buffer-window buffer 0)))
		(unless (and not-this-window
			     (eq window (selected-window)))
		  window))
	      (get-largest-window 0 nil not-this-window)))

 > I have no choice :-)

Me neither.  Life is deterministic (if you know all the parameters).

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> Actually, it already does, but `display-buffer-in-previous-window'
>> doesn't behave as expected.  Seems it fails.  Maybe the recursive edit
>> the debugger uses interferes, dunno.
>
> No.  It's the default setting of 'debugger-bury-or-kill'.  With
> 'append' it does reuse the previous window.  With the default 'bury'
> the buffer is not added to the window's list of previous buffers.  We
> can set the default to 'append' but then the *backtrace* buffer may
> eventually show up when invoking 'previous-buffer' which can be a
> nuisance, sometimes.

Another problem with 'append' is that when the user switches
to the window where *Backtrace* was displayed last time,
and types 'C-x C-e' in that window, then *Backtrace* will be
displayed in the same window.  Maybe it should have
(inhibit-same-window . t)?

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Another problem with 'append' is that when the user switches to the
> window where *Backtrace* was displayed last time, and types 'C-x C-e'
> in that window, then *Backtrace* will be displayed in the same window.
> Maybe it should have (inhibit-same-window . t)?

I guess that would make sense.


Michael.

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> Another problem with 'append' is that when the user switches to the
>> window where *Backtrace* was displayed last time, and types 'C-x C-e'
>> in that window, then *Backtrace* will be displayed in the same window.
>> Maybe it should have (inhibit-same-window . t)?
>
> I guess that would make sense.

In bug#32790 we discussed a possibility to use the display action
display-buffer-below-selected for the *Backtrace* buffer that will
predictably always display *Backtrace* below from the selected window.

Maybe this makes sense as well?

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> >> Another problem with 'append' is that when the user switches to the
> >> window where *Backtrace* was displayed last time, and types 'C-x C-e'
> >> in that window, then *Backtrace* will be displayed in the same window.
> >> Maybe it should have (inhibit-same-window . t)?
> >
> > I guess that would make sense.
>
> In bug#32790 we discussed a possibility to use the display action
> display-buffer-below-selected for the *Backtrace* buffer that will
> predictably always display *Backtrace* below from the selected window.
>
> Maybe this makes sense as well?

A lot of users may like this, but not all I think at least if you can't
configure it away.  It's hard to tell how it feels unless you try it for
a while.

Michael.

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> In bug#32790 we discussed a possibility to use the display action
>> display-buffer-below-selected for the *Backtrace* buffer that will
>> predictably always display *Backtrace* below from the selected window.
>>
>> Maybe this makes sense as well?
>
> A lot of users may like this, but not all I think at least if you can't
> configure it away.  It's hard to tell how it feels unless you try it for
> a while.

It will be possible to configure it after adding the new action to the end:

diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
index 7fc2b41c70..dc5230b82a 100644
--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -239,7 +239,8 @@ debug
 	      (pop-to-buffer
 	       debugger-buffer
 	       `((display-buffer-reuse-window
-		  display-buffer-in-previous-window)
+		  display-buffer-in-previous-window
+		  display-buffer-below-selected)
 		 . (,(when (and (window-live-p debugger-previous-window)
 				(frame-visible-p
 				 (window-frame debugger-previous-window)))

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> It will be possible to configure it after adding the new action to the
> end:
>
> diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
> index 7fc2b41c70..dc5230b82a 100644
> --- a/lisp/emacs-lisp/debug.el
> +++ b/lisp/emacs-lisp/debug.el
> @@ -239,7 +239,8 @@ debug
>  	      (pop-to-buffer
>  	       debugger-buffer
>  	       `((display-buffer-reuse-window
> -		  display-buffer-in-previous-window)
> +		  display-buffer-in-previous-window
> +		  display-buffer-below-selected)
>  		 . (,(when (and (window-live-p
> debugger-previous-window)
>  				(frame-visible-p
>  				 (window-frame
> debugger-previous-window)))

Under which conditions will `display-buffer-below-selected' be chosen?
Only when there is no previous window?


Michael.

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> It will be possible to configure it after adding the new action to the
>> end:
>>
>> diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
>> index 7fc2b41c70..dc5230b82a 100644
>> --- a/lisp/emacs-lisp/debug.el
>> +++ b/lisp/emacs-lisp/debug.el
>> @@ -239,7 +239,8 @@ debug
>>  	      (pop-to-buffer
>>  	       debugger-buffer
>>  	       `((display-buffer-reuse-window
>> -		  display-buffer-in-previous-window)
>> +		  display-buffer-in-previous-window
>> +		  display-buffer-below-selected)
>>  		 . (,(when (and (window-live-p
>> debugger-previous-window)
>>  				(frame-visible-p
>>  				 (window-frame
>> debugger-previous-window)))
>
> Under which conditions will `display-buffer-below-selected' be chosen?
> Only when there is no previous window?

If I understand correctly the logic of display-buffer then yes,
it should display it below the selected only when there is no
previous window (and no window is reused).

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> If I understand correctly the logic of display-buffer then yes,
> it should display it below the selected only when there is no
> previous window (and no window is reused).

That's ok I think.

How does your change behave when the height of the window below the
selected one is small?  Should we specify a minimum height somewhere?


Michael.

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> If I understand correctly the logic of display-buffer then yes,
>> it should display it below the selected only when there is no
>> previous window (and no window is reused).
>
> That's ok I think.
>
> How does your change behave when the height of the window below the
> selected one is small?  Should we specify a minimum height somewhere?

Before proposing this change, I extensively tested it with small heights,
and I see that in case of small heights, display-buffer-below-selected
reuses a window that is below from the selected, that is a good behavior.  

A minimum height is defined by window-min-height, by default it's 4.
But for *Backtrace* maybe we should let-bind a larger value?

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> A minimum height is defined by window-min-height, by default it's 4.
> But for *Backtrace* maybe we should let-bind a larger value?

I think that could be appropriate.

That's now something that display-buffer-alist can't do: keep the
default action(s), but specify parameters, like a larger
window-min-height.  I mean, there is no way to change that value unless
you around-advice the whole function.


Michael.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > That's now something that display-buffer-alist can't do: keep the
 > default action(s), but specify parameters, like a larger
 > window-min-height.  I mean, there is no way to change that value unless
 > you around-advice the whole function.

The caller of 'display-buffer' could bind 'window-min-height' to
another value around the call.  But that's a bad idea because it may
override a user customization and because a high value would not allow
a window to be created even if other windows would tolerate the lower
value while a low value would allow other windows to shrink to that
value as well when a new window is created.

Couldn't setting a 'window-height' action alist entry help here?
Maybe with a suitable function?

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> Couldn't setting a 'window-height' action alist entry help here?

There is no need to set 'window-height' because
display-buffer-below-selected calculates the right height.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > There is no need to set 'window-height' because
 > display-buffer-below-selected calculates the right height.

But only if you ask it to do that, for example, with a 'window-height'
alist entry.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> There is no need to set 'window-height' because
>> display-buffer-below-selected calculates the right height.
>
> But only if you ask it to do that, for example, with a 'window-height'
> alist entry.

I see that it already does the right thing by default.

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> That's now something that display-buffer-alist can't do: keep the
>> default action(s), but specify parameters, like a larger
>> window-min-height.  I mean, there is no way to change that value unless
>> you around-advice the whole function.
>
> The caller of 'display-buffer' could bind 'window-min-height' to
> another value around the call.  But that's a bad idea because it may
> override a user customization and because a high value would not allow
> a window to be created even if other windows would tolerate the lower
> value while a low value would allow other windows to shrink to that
> value as well when a new window is created.
>
> Couldn't setting a 'window-height' action alist entry help here?
> Maybe with a suitable function?

I still don't understand why it's impossible to support such uses?

diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
index 7fc2b41c70..6d72616dbc 100644
--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -239,11 +239,13 @@ debug
 	      (pop-to-buffer
 	       debugger-buffer
 	       `((display-buffer-reuse-window
-		  display-buffer-in-previous-window)
-		 . (,(when (and (window-live-p debugger-previous-window)
-				(frame-visible-p
-				 (window-frame debugger-previous-window)))
-		       `(previous-window . ,debugger-previous-window)))))
+		  display-buffer-in-previous-window
+		  display-buffer-below-selected)
+		 . ((window-min-height . 10)
+		    ,@(when (and (window-live-p debugger-previous-window)
+				 (frame-visible-p
+				  (window-frame debugger-previous-window)))
+		        `((previous-window . ,debugger-previous-window))))))
 	      (setq debugger-window (selected-window))
 	      (if (eq debugger-previous-window debugger-window)
 		  (when debugger-jumping-flag

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > I still don't understand why it's impossible to support such uses?
 >
 > diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
 > index 7fc2b41c70..6d72616dbc 100644
 > --- a/lisp/emacs-lisp/debug.el
 > +++ b/lisp/emacs-lisp/debug.el
 > @@ -239,11 +239,13 @@ debug
 >   	      (pop-to-buffer
 >   	       debugger-buffer
 >   	       `((display-buffer-reuse-window
 > -		  display-buffer-in-previous-window)
 > -		 . (,(when (and (window-live-p debugger-previous-window)
 > -				(frame-visible-p
 > -				 (window-frame debugger-previous-window)))
 > -		       `(previous-window . ,debugger-previous-window)))))
 > +		  display-buffer-in-previous-window
 > +		  display-buffer-below-selected)
 > +		 . ((window-min-height . 10)

What would the semantics of that 'window-min-height' entry be?

(1) When splitting a window, the new window must be at least 10 lines
     high.

(2) When splitting a window, both the old and the new window must be
     at least 10 lines high after the split.

(3) When splitting a window, every window must be at least 10 lines
     high after the split.

And what would we do if before the split a window is less high than 10
lines?

Why can't we just follow the doc-string of 'window-min-height'?

    Applications should never rebind this variable.  To resize a
    window to a height less than the one specified here, an
    application should instead call ‘window-resize’ with a non-nil
    IGNORE argument.  In order to have ‘split-window’ make a window
    shorter, explicitly specify the SIZE argument of that function.

 > +		    ,@(when (and (window-live-p debugger-previous-window)
 > +				 (frame-visible-p
 > +				  (window-frame debugger-previous-window)))
 > +		        `((previous-window . ,debugger-previous-window))))))
 >   	      (setq debugger-window (selected-window))
 >   	      (if (eq debugger-previous-window debugger-window)
 >   		  (when debugger-jumping-flag

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> I still don't understand why it's impossible to support such uses?
>>
>> diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
>> index 7fc2b41c70..6d72616dbc 100644
>> --- a/lisp/emacs-lisp/debug.el
>> +++ b/lisp/emacs-lisp/debug.el
>> @@ -239,11 +239,13 @@ debug
>>   	      (pop-to-buffer
>>   	       debugger-buffer
>>   	       `((display-buffer-reuse-window
>> -		  display-buffer-in-previous-window)
>> -		 . (,(when (and (window-live-p debugger-previous-window)
>> -				(frame-visible-p
>> -				 (window-frame debugger-previous-window)))
>> -		       `(previous-window . ,debugger-previous-window)))))
>> +		  display-buffer-in-previous-window
>> +		  display-buffer-below-selected)
>> +		 . ((window-min-height . 10)
>
> What would the semantics of that 'window-min-height' entry be?
>
> (1) When splitting a window, the new window must be at least 10 lines
>     high.
>
> (2) When splitting a window, both the old and the new window must be
>     at least 10 lines high after the split.
>
> (3) When splitting a window, every window must be at least 10 lines
>     high after the split.
>
> And what would we do if before the split a window is less high than 10
> lines?

I think the semantics should be:

(4) If the height of the new window will be less than 10 lines specified
    by window-min-height, then display the buffer a window below
    from the selected window.

IIUC, currently 'window-min-height' with the default of 4 lines works like this?

> Why can't we just follow the doc-string of 'window-min-height'?
>
>    Applications should never rebind this variable.  To resize a
>    window to a height less than the one specified here, an
>    application should instead call ‘window-resize’ with a non-nil
>    IGNORE argument.  In order to have ‘split-window’ make a window
>    shorter, explicitly specify the SIZE argument of that function.

How then the code will look like?  I guess it will be quite complex
and not declarative.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > I think the semantics should be:
 >
 > (4) If the height of the new window will be less than 10 lines specified
 >      by window-min-height, then display the buffer a window below
 >      from the selected window.
 >
 > IIUC, currently 'window-min-height' with the default of 4 lines works like this?

Not really: 'window-min-height' is an option which causes functions to
check the height of all windows wrt a potential change.  If, after the
change, the height of one window would drop below that value, the
change is not made.  One can make an exeption for a specific window,
for example the one that should be resized or newly made, but not for
other windows that are probably not related to the change.

But I don't fully understand (4): What does "If the height of the new
window will be less than 10 lines specified by window-min-height"
mean?  Does it stand for "if (split-window nil -10) fails" to produce
a 10 line window?  And what would we do then if the window below the
selected one has less than ten lines?

 >>     Applications should never rebind this variable.  To resize a
 >>     window to a height less than the one specified here, an
 >>     application should instead call ‘window-resize’ with a non-nil
 >>     IGNORE argument.  In order to have ‘split-window’ make a window
 >>     shorter, explicitly specify the SIZE argument of that function.
 >
 > How then the code will look like?  I guess it will be quite complex
 > and not declarative.

Why so?  What is more declarative than having code say what size the
old or new window should have?  If we want such a window to always
keep some minimum size, we can obviously add an according parameter.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> 'window-min-height' is an option which causes functions to
> check the height of all windows wrt a potential change.  If, after the
> change, the height of one window would drop below that value, the
> change is not made.  One can make an exeption for a specific window,
> for example the one that should be resized or newly made, but not for
> other windows that are probably not related to the change.

I meant the same, but with one change: check the height of all windows
with the default value of 'window-min-height' (i.e. 4), but check the
height of the new created window with the value 'window-min-height'
(e.g. 10) specified in an alist that should override the default value
only for the window created by display-buffer-below-selected.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 >> 'window-min-height' is an option which causes functions to
 >> check the height of all windows wrt a potential change.  If, after the
 >> change, the height of one window would drop below that value, the
 >> change is not made.  One can make an exeption for a specific window,
 >> for example the one that should be resized or newly made, but not for
 >> other windows that are probably not related to the change.
 >
 > I meant the same, but with one change: check the height of all windows
 > with the default value of 'window-min-height' (i.e. 4), but check the
 > height of the new created window with the value 'window-min-height'
 > (e.g. 10) specified in an alist that should override the default value
 > only for the window created by display-buffer-below-selected.

So you mean that if Emacs can't fulfill a 'window-height' contract for
a new window below the selected one, it shouldn't make a new one in
the first place?  Then with an an alist entry called 'min-height' we
could rewrite 'display-buffer-below-selected' as follows:

(defun display-buffer-below-selected (buffer alist)
   "Try displaying BUFFER in a window below the selected window.
If there is a window below the selected one and that window
already displays BUFFER, use that window.  Otherwise, try to
create a new window below the selected one and show BUFFER there.
If that attempt fails as well and there is a non-dedicated window
below the selected one, use that window."
   (let ((min-height (cdr (assq 'min-height alist)))
	window)
     (or (and (setq window (window-in-direction 'below))
	     (eq buffer (window-buffer window))
	     (window--display-buffer buffer window 'reuse alist))
	(and (not (frame-parameter nil 'unsplittable))
	     (or (not (numberp min-height))
		 (window-sizable-p nil (- min-height)))
	     (let ((split-height-threshold 0)
		   split-width-threshold)
	       (setq window (window--try-to-split-window
                              (selected-window) alist)))
	     (window--display-buffer
	      buffer window 'window alist display-buffer-mark-dedicated))
	(and (setq window (window-in-direction 'below))
	     (not (window-dedicated-p window))
	     (window--display-buffer
	      buffer window 'reuse alist display-buffer-mark-dedicated)))))


But would we (re-)use a window if it is not as large as 'min-height'?
Would we try to enlarge such a window?  As far as we can?

BTW: Calling 'window--try-to-split-window' above is butt-ugly.  We
should simply call 'split-window' instead.  I have no idea what came
to my mind when I wrote that.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> So you mean that if Emacs can't fulfill a 'window-height' contract for
> a new window below the selected one, it shouldn't make a new one in
> the first place?  Then with an an alist entry called 'min-height' we
> could rewrite 'display-buffer-below-selected' as follows:

Thanks, I tried and it's going without a hitch.

> But would we (re-)use a window if it is not as large as 'min-height'?
> Would we try to enlarge such a window?  As far as we can?

Hmm, enlarge looks like a reasonable choice.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 >> So you mean that if Emacs can't fulfill a 'window-height' contract for
 >> a new window below the selected one, it shouldn't make a new one in
 >> the first place?  Then with an an alist entry called 'min-height' we
 >> could rewrite 'display-buffer-below-selected' as follows:
 >
 > Thanks, I tried and it's going without a hitch.

OK.  This means we will have to change 'display-buffer-pop-up-window'
and 'display-buffer-at-bottom' accordingly.

 >> But would we (re-)use a window if it is not as large as 'min-height'?
 >> Would we try to enlarge such a window?  As far as we can?
 >
 > Hmm, enlarge looks like a reasonable choice.

Mine was an ill-posed question.  What we have to do is:

(1) Decide whether a specific window can be (re-)used.  Should we
refute it when the window cannot be enlarged to 'min-height' lines?
The decision would have to be made via 'window-resizable-p' and its
IGNORE argument set to the window itself so we can, for example,
(re-)use a preserved size window showing some other buffer.

(2) Actually resize that window via a 'window-height' entry.  This is
independent from (1).  Processing a 'window-height' entry is just some
sort of bonus work 'display-buffer' does for the convenience of the
user.  It in now way affects the decision which window is chosen.

So please think of any bad consequences of what we decide in (1) like
not using _any_ window on the selected frame because none of them fits
the 'min-height' constraint.  Consider a default two windows frame
where the size of the selected window is preserved.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> (1) Decide whether a specific window can be (re-)used.  Should we
> refute it when the window cannot be enlarged to 'min-height' lines?
> The decision would have to be made via 'window-resizable-p' and its
> IGNORE argument set to the window itself so we can, for example,
> (re-)use a preserved size window showing some other buffer.
>
> (2) Actually resize that window via a 'window-height' entry.  This is
> independent from (1).  Processing a 'window-height' entry is just some
> sort of bonus work 'display-buffer' does for the convenience of the
> user.  It in now way affects the decision which window is chosen.
>
> So please think of any bad consequences of what we decide in (1) like
> not using _any_ window on the selected frame because none of them fits
> the 'min-height' constraint.  Consider a default two windows frame
> where the size of the selected window is preserved.

Maybe simply display the buffer in the below window regardless of its
size?  Because it makes no sense for display-buffer-below-selected to
display the buffer in a window other than below.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 >> (1) Decide whether a specific window can be (re-)used.  Should we
 >> refute it when the window cannot be enlarged to 'min-height' lines?
 >> The decision would have to be made via 'window-resizable-p' and its
 >> IGNORE argument set to the window itself so we can, for example,
 >> (re-)use a preserved size window showing some other buffer.
 >>
 >> (2) Actually resize that window via a 'window-height' entry.  This is
 >> independent from (1).  Processing a 'window-height' entry is just some
 >> sort of bonus work 'display-buffer' does for the convenience of the
 >> user.  It in now way affects the decision which window is chosen.
 >>
 >> So please think of any bad consequences of what we decide in (1) like
 >> not using _any_ window on the selected frame because none of them fits
 >> the 'min-height' constraint.  Consider a default two windows frame
 >> where the size of the selected window is preserved.
 >
 > Maybe simply display the buffer in the below window regardless of its
 > size?  Because it makes no sense for display-buffer-below-selected to
 > display the buffer in a window other than below.

But then the same argument holds for popping up a new window.  Even
if we can't make the new window as large as we want, popping it up
below the selected one is the only thing that makes sense if the
selected window is at the bottom of the frame.  Unless we decide that
failing should be better than not making the window high enough.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>>> (1) Decide whether a specific window can be (re-)used.  Should we
>>> refute it when the window cannot be enlarged to 'min-height' lines?
>>> The decision would have to be made via 'window-resizable-p' and its
>>> IGNORE argument set to the window itself so we can, for example,
>>> (re-)use a preserved size window showing some other buffer.
>>>
>>> (2) Actually resize that window via a 'window-height' entry.  This is
>>> independent from (1).  Processing a 'window-height' entry is just some
>>> sort of bonus work 'display-buffer' does for the convenience of the
>>> user.  It in now way affects the decision which window is chosen.
>>>
>>> So please think of any bad consequences of what we decide in (1) like
>>> not using _any_ window on the selected frame because none of them fits
>>> the 'min-height' constraint.  Consider a default two windows frame
>>> where the size of the selected window is preserved.
>>
>> Maybe simply display the buffer in the below window regardless of its
>> size?  Because it makes no sense for display-buffer-below-selected to
>> display the buffer in a window other than below.
>
> But then the same argument holds for popping up a new window.  Even
> if we can't make the new window as large as we want, popping it up
> below the selected one is the only thing that makes sense if the
> selected window is at the bottom of the frame.  Unless we decide that
> failing should be better than not making the window high enough.

Maybe I misunderstand something, but I see that already everything is
working fine.  When I tried with display-buffer-below-selected
to cause an error in a narrow buffer at the bottom of the frame,
then the *Backtrace* buffer is displayed in a new window created
by horizontal splitting of the largest window on the frame.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > Maybe I misunderstand something, but I see that already everything is
 > working fine.  When I tried with display-buffer-below-selected
 > to cause an error in a narrow buffer at the bottom of the frame,
 > then the *Backtrace* buffer is displayed in a new window created
 > by horizontal splitting of the largest window on the frame.

I never doubted that it works correctly (IIRC Michael did).  But from
what you tell above it's obvious that you tried with customizations of
the initial frame size which cause 'split-window-sensibly' to prefer a
horizontal split over a vertical one.  Right?  If so, then since most
users of Emacs do not have such customizations, your invocation hardly
qualifies as of the emacs -Q type.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> Maybe I misunderstand something, but I see that already everything is
>> working fine.  When I tried with display-buffer-below-selected
>> to cause an error in a narrow buffer at the bottom of the frame,
>> then the *Backtrace* buffer is displayed in a new window created
>> by horizontal splitting of the largest window on the frame.
>
> I never doubted that it works correctly (IIRC Michael did).  But from
> what you tell above it's obvious that you tried with customizations of
> the initial frame size which cause 'split-window-sensibly' to prefer a
> horizontal split over a vertical one.  Right?  If so, then since most
> users of Emacs do not have such customizations, your invocation hardly
> qualifies as of the emacs -Q type.

I tried in a wide frame, but trying in a narrow frame is even better:
it selects a large window without splitting it.

What is much worse is that subsequent calls in a narrow frame
display the *Backtrace* buffer each time in another window -
the window is not reused where it was displayed previously.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > I tried in a wide frame, but trying in a narrow frame is even better:
 > it selects a large window without splitting it.
 >
 > What is much worse is that subsequent calls in a narrow frame
 > display the *Backtrace* buffer each time in another window -
 > the window is not reused where it was displayed previously.

Does 'display-buffer-in-previous-window' fail and if so why?

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> What is much worse is that subsequent calls in a narrow frame
>> display the *Backtrace* buffer each time in another window -
>> the window is not reused where it was displayed previously.
>
> Does 'display-buffer-in-previous-window' fail and if so why?

Yes, it fails.  Do you see the same?

I only added display-buffer-below-selected to pop-to-buffer
of "*Backtrace*" after display-buffer-in-previous-window,
and in `emacs -Q` with 3 windows where the bottom window is
very low, subsequent errors are displayed in different windows.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > I only added display-buffer-below-selected to pop-to-buffer
 > of "*Backtrace*" after display-buffer-in-previous-window,
 > and in `emacs -Q` with 3 windows where the bottom window is
 > very low, subsequent errors are displayed in different windows.

Like this

	      (pop-to-buffer
	       debugger-buffer
	       `((display-buffer-reuse-window
		  display-buffer-in-previous-window
                   display-buffer-below-selected)
		 . (,(when (and (window-live-p debugger-previous-window)
				(frame-visible-p
				 (window-frame debugger-previous-window)))
		       `(previous-window . ,debugger-previous-window)))))

I presume.  This will, in the first invocation, make a new window below
the selected one or reuse such a window because there is no previous
window.  Later on, that window gets reused here as expected,
regardless of whether the frame is wide or not.  With emacs -Q, at
least.  Maybe you have additional customizations or changes at work?

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> I only added display-buffer-below-selected to pop-to-buffer
>> of "*Backtrace*" after display-buffer-in-previous-window,
>> and in `emacs -Q` with 3 windows where the bottom window is
>> very low, subsequent errors are displayed in different windows.
>
> Like this
>
> 	      (pop-to-buffer
> 	       debugger-buffer
> 	       `((display-buffer-reuse-window
> 		  display-buffer-in-previous-window
>                   display-buffer-below-selected)
> 		 . (,(when (and (window-live-p debugger-previous-window)
> 				(frame-visible-p
> 				 (window-frame debugger-previous-window)))
> 		       `(previous-window . ,debugger-previous-window)))))

Exactly.

> I presume.  This will, in the first invocation, make a new window below
> the selected one or reuse such a window because there is no previous
> window.  Later on, that window gets reused here as expected,
> regardless of whether the frame is wide or not.  With emacs -Q, at
> least.  Maybe you have additional customizations or changes at work?

With emacs -Q and without additional customizations, every error
(e.g. evaluating a non-existent variable) is shown in a different window
(first in 1, then in 2, then again in 1):

+---------------------+
| 1.                  |
|                     |
+---------------------+
| 2.                  |
|                     |
+---------------------+
| low selected window |
+---------------------+

This bug can be avoided by adding display-buffer-at-bottom
after display-buffer-below-selected, i.e. by using such actions:

display-buffer-reuse-window
display-buffer-in-previous-window
display-buffer-below-selected
display-buffer-at-bottom

This provides a nicer behavior because display-buffer-at-bottom tries
to resize other windows to accommodate the *Backtrace*.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > With emacs -Q and without additional customizations, every error
 > (e.g. evaluating a non-existent variable) is shown in a different window
 > (first in 1, then in 2, then again in 1):
 >
 > +---------------------+
 > | 1.                  |
 > |                     |
 > +---------------------+
 > | 2.                  |
 > |                     |
 > +---------------------+
 > | low selected window |
 > +---------------------+
 >

I see.  The window at the bottom must be made small enough here so it
can't be split.  I suppose the behavior you observe is caused by the
already familiar

             ;; Forget debugger window, it won't be back (Bug#17882).
             (setq debugger-previous-window nil))

because 'debugger-previous-window' is nil here when it happens.

 > This bug can be avoided by adding display-buffer-at-bottom
 > after display-buffer-below-selected, i.e. by using such actions:
 >
 > display-buffer-reuse-window
 > display-buffer-in-previous-window
 > display-buffer-below-selected
 > display-buffer-at-bottom
 >
 > This provides a nicer behavior because display-buffer-at-bottom tries
 > to resize other windows to accommodate the *Backtrace*.

I think we should first investigate the 'debugger-previous-window'
resettings.  Maybe Michael can help.

martin

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> > This provides a nicer behavior because display-buffer-at-bottom tries
> > to resize other windows to accommodate the *Backtrace*.
>
> I think we should first investigate the 'debugger-previous-window'
> resettings.  Maybe Michael can help.

I'm not sure how I can be of help.

There are only two places where debugger-previous-window is set - both
in `debug': in the first, the value is set when the debugger pops up, to
the window that has been chosen to display it.  In the second place,
it's reset to nil when the debugger "won't be back".

So, when the value is a (live) window, it should be respected.  I didn't
follow your discussion very attentively, but I'm not sure how the
debugger-previous-window variable is concerned in what you discussed
recently.  AFAIK its only use is to remember the window while a debugger
session is still active.


Michael.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

 > There are only two places where debugger-previous-window is set - both
 > in `debug': in the first, the value is set when the debugger pops up, to
 > the window that has been chosen to display it.  In the second place,
 > it's reset to nil when the debugger "won't be back".
 >
 > So, when the value is a (live) window, it should be respected.  I didn't
 > follow your discussion very attentively, but I'm not sure how the
 > debugger-previous-window variable is concerned in what you discussed
 > recently.  AFAIK its only use is to remember the window while a debugger
 > session is still active.

You're right - FWIW this is the same bug I proposed to fix earlier
with the patch I reattach now.  Juri, you never tried it, I suppose?

martin

[-- Attachment #2: debug.diff --]
[-- Type: text/plain, Size: 2177 bytes --]

--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -101,7 +101,10 @@ debugger-old-buffer
   "This is the buffer that was current when the debugger was entered.")
 
 (defvar debugger-previous-window nil
-  "This is the window last showing the debugger buffer.")
+  "The last debugger window from the same session.")
+
+(defvar debugger-pre-previous-window nil
+  "The last debugger window from the previous session.")
 
 (defvar debugger-previous-window-height nil
   "The last recorded height of `debugger-previous-window'.")
@@ -240,10 +243,16 @@ debug
 	       debugger-buffer
 	       `((display-buffer-reuse-window
 		  display-buffer-in-previous-window)
-		 . (,(when (and (window-live-p debugger-previous-window)
-				(frame-visible-p
-				 (window-frame debugger-previous-window)))
-		       `(previous-window . ,debugger-previous-window)))))
+		 . (,(cond
+                      ((and (window-live-p debugger-previous-window)
+			    (frame-visible-p
+			     (window-frame debugger-previous-window)))
+		       `(previous-window . ,debugger-previous-window))
+                      ((and (window-live-p debugger-pre-previous-window)
+                            (eq (window-frame debugger-pre-previous-window)
+                                (selected-frame)))
+		       `(previous-window . ,debugger-pre-previous-window)))
+                    (inhibit-same-window . t))))
 	      (setq debugger-window (selected-window))
 	      (if (eq debugger-previous-window debugger-window)
 		  (when debugger-jumping-flag
@@ -297,7 +306,9 @@ debug
 		(quit-restore-window debugger-window debugger-bury-or-kill)
 		;; Restore current buffer (Bug#12502).
 		(set-buffer debugger-old-buffer)))
-            ;; Forget debugger window, it won't be back (Bug#17882).
+            ;; Forget debugger window, it won't be back (Bug#17882)
+            ;; unless it's on the selected frame (Bug#32825).
+            (setq debugger-pre-previous-window debugger-previous-window)
             (setq debugger-previous-window nil))
           ;; Restore previous state of debugger-buffer in case we were
           ;; in a recursive invocation of the debugger, otherwise just

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> There are only two places where debugger-previous-window is set - both
>> in `debug': in the first, the value is set when the debugger pops up, to
>> the window that has been chosen to display it.  In the second place,
>> it's reset to nil when the debugger "won't be back".
>>
>> So, when the value is a (live) window, it should be respected.  I didn't
>> follow your discussion very attentively, but I'm not sure how the
>> debugger-previous-window variable is concerned in what you discussed
>> recently.  AFAIK its only use is to remember the window while a debugger
>> session is still active.
>
> You're right - FWIW this is the same bug I proposed to fix earlier
> with the patch I reattach now.  Juri, you never tried it, I suppose?

I tried it long ago to see it works fine, and later reverted locally
because I thought already you pushed it to master.

Now I tried again with display-buffer-below-selected, and it still
works fine.

But still it seems better would be to add display-buffer-at-bottom
after display-buffer-below-selected:

display-buffer-reuse-window
display-buffer-in-previous-window
display-buffer-below-selected
display-buffer-at-bottom

because display-buffer-at-bottom tries to resize other windows
to accommodate the *Backtrace* window.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > I tried it long ago to see it works fine, and later reverted locally
 > because I thought already you pushed it to master.
 >
 > Now I tried again with display-buffer-below-selected, and it still
 > works fine.
 >
 > But still it seems better would be to add display-buffer-at-bottom
 > after display-buffer-below-selected:
 >
 > display-buffer-reuse-window
 > display-buffer-in-previous-window
 > display-buffer-below-selected
 > display-buffer-at-bottom
 >
 > because display-buffer-at-bottom tries to resize other windows
 > to accommodate the *Backtrace* window.

I certainly won't object but we have to make the previous-window
behavior DTRT so the 'display-buffer-at-bottom' won't hide its
misbehavior.

Currently we use a window's previous buffers for three things:

(1) For 'switch-to-prev-buffer'.

(2) To find a buffer to display when killing or burying a window's
     buffer and the window shall be kept.

(3) For finding a window in 'display-buffer-in-previous-window'.

Personally I don't care about (2).  But two things about (1) that
annoy me in practice are: When the window-local buffer list is
exhausted I get a buffer from the frame-local or global lists, so I
often enough get TAGS or other intestines dished in that window and,
to double my pleasure, indirectly have these enter the window-local
list.  I'd rather restart with a buffer from the window-local list
provided that list is "long enough".  That's fuzzy to implement.

And, I get too many irrelevant buffers like temporary ones from the
window-local list.  OTOH it's just the temporary buffers we want to
keep there because of (3).  Moreover, when I'm in a window reused by
*Help* and I want to temporarily switch to that window's previous
buffer then switching back to the window's next buffer should probably
get me back to *Help*.  So what I'd like is yet another notion of
fuzziness that after some time forgets about temporary buffers shown
in a window in the past, including *Backtrace*.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> Currently we use a window's previous buffers for three things:
>
> (1) For 'switch-to-prev-buffer'.
>
> (2) To find a buffer to display when killing or burying a window's
>     buffer and the window shall be kept.
>
> (3) For finding a window in 'display-buffer-in-previous-window'.
>
> Personally I don't care about (2).  But two things about (1) that
> annoy me in practice are: When the window-local buffer list is
> exhausted I get a buffer from the frame-local or global lists, so I
> often enough get TAGS or other intestines dished in that window and,

Regarding TAGS, I spend much time killing TAGS buffers, but they
quickly reappear in the buffer list like in a whac-a-mole type of game.
Shouldn't such internal types of buffers be named with a leading space
in their buffer names?

> to double my pleasure, indirectly have these enter the window-local
> list.  I'd rather restart with a buffer from the window-local list
> provided that list is "long enough".  That's fuzzy to implement.

You mean a cyclic window-local buffer list?

> And, I get too many irrelevant buffers like temporary ones from the
> window-local list.  OTOH it's just the temporary buffers we want to
> keep there because of (3).  Moreover, when I'm in a window reused by
> *Help* and I want to temporarily switch to that window's previous
> buffer then switching back to the window's next buffer should probably
> get me back to *Help*.  So what I'd like is yet another notion of
> fuzziness that after some time forgets about temporary buffers shown
> in a window in the past, including *Backtrace*.

Maybe the notion of burying should also apply to window-local
buffer list?  So burying a buffer should push it to the end of
window-local buffer list?

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > Regarding TAGS, I spend much time killing TAGS buffers, but they
 > quickly reappear in the buffer list like in a whac-a-mole type of game.
 > Shouldn't such internal types of buffers be named with a leading space
 > in their buffer names?

Etags files are called TAGS and we usually set the buffer name from
the name of the file it's visiting.  We should be able to prepend a
space but I have no idea where and when we visit the TAGS file.

 >> I'd rather restart with a buffer from the window-local list
 >> provided that list is "long enough".  That's fuzzy to implement.
 >
 > You mean a cyclic window-local buffer list?

If it's long enough, yes.  Note also that once a member of the global
list has been taken it will pollute the local list forever thus also
needlessly increasing the list of previous buffers for a window.

More precisely, the problem is that of "navigational security"
(alternating 'switch-to-prev-buffer' and 'switch-to-next-buffer' calls
should reliably reproduce the buffer previously shown in a window to
avoid violating the principle of least surprise) vs "minimum
annoyance" (that of not switching to a buffer a user expressly doesn't
want to see).

So I think that while the solution is to not allow
'switch-to-prev-buffer' to switch to such an unwanted buffer, we
should allow 'switch-to-next-buffer' to switch to it.  But I haven't
yet thought about all the implications.

Also I'm not sure whether we should maintain for each window separate
lists of buffers we do not want to switch to but we might want to
consult in 'display-buffer-in-previous-window' or to leave such
buffers in the windows' lists of previous buffers and have
'switch-to-prev-buffer' skip such buffers with the help of some
predicate.  The latter would be more likely the way to go because we
then could allow a simple user option to provide that predicate.

 > Maybe the notion of burying should also apply to window-local
 > buffer list?  So burying a buffer should push it to the end of
 > window-local buffer list?

If 'switch-to-prev-buffer' didn't already do that it would be severely
broken.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> Regarding TAGS, I spend much time killing TAGS buffers, but they
>> quickly reappear in the buffer list like in a whac-a-mole type of game.
>> Shouldn't such internal types of buffers be named with a leading space
>> in their buffer names?
>
> Etags files are called TAGS and we usually set the buffer name from
> the name of the file it's visiting.  We should be able to prepend a
> space but I have no idea where and when we visit the TAGS file.

This is easy to fix, but I'm not sure if this might break some packages
that depend on TAGS buffers with original names.

>>> I'd rather restart with a buffer from the window-local list
>>> provided that list is "long enough".  That's fuzzy to implement.
>>
>> You mean a cyclic window-local buffer list?
>
> If it's long enough, yes.  Note also that once a member of the global
> list has been taken it will pollute the local list forever thus also
> needlessly increasing the list of previous buffers for a window.
>
> More precisely, the problem is that of "navigational security"
> (alternating 'switch-to-prev-buffer' and 'switch-to-next-buffer' calls
> should reliably reproduce the buffer previously shown in a window to
> avoid violating the principle of least surprise) vs "minimum
> annoyance" (that of not switching to a buffer a user expressly doesn't
> want to see).
>
> So I think that while the solution is to not allow
> 'switch-to-prev-buffer' to switch to such an unwanted buffer, we
> should allow 'switch-to-next-buffer' to switch to it.  But I haven't
> yet thought about all the implications.
>
> Also I'm not sure whether we should maintain for each window separate
> lists of buffers we do not want to switch to but we might want to
> consult in 'display-buffer-in-previous-window' or to leave such
> buffers in the windows' lists of previous buffers and have
> 'switch-to-prev-buffer' skip such buffers with the help of some
> predicate.  The latter would be more likely the way to go because we
> then could allow a simple user option to provide that predicate.

Maybe better to represent a list of prev/next buffers as a tree?
Then inserting a new buffer inside it will create a leaf that
can be ignored for navigation.  An analogy of this is undo-tree.

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> Maybe better to represent a list of prev/next buffers as a tree?
> Then inserting a new buffer inside it will create a leaf that
> can be ignored for navigation.  An analogy of this is undo-tree.

More precisely, navigating in the tree trunk and ignoring branches.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 >> Maybe better to represent a list of prev/next buffers as a tree?
 >> Then inserting a new buffer inside it will create a leaf that
 >> can be ignored for navigation.  An analogy of this is undo-tree.
 >
 > More precisely, navigating in the tree trunk and ignoring branches.

Note that 'display-buffer-in-previous-window' doesn't care about the
order in which a buffer appears in a window's previous buffers list.
It only wants to know whether it's there and traversing a tree for
that purpose looks like overkill.

OTOH we would still have to decide what to do with a window's buffer
when displaying another buffer in that window via 'display-buffer':
Make it the first buffer we would want to switch to in the next
'switch-to-prev-buffer' call or make it insignificant (a leaf in your
parlance).

I currently tend to favor a solution like the below (we could also use
the 'buffer-predicate' frame parameter for that purpose but that would
affect 'other-buffer' as well, something I'd like to avoid).

The solution below should behave as follows: Assume TAGS is shown in
the selected window.  Then doing 'switch-to-prev-buffer' followed by
'switch-to-next-buffer' there should get me back to TAGS.  Doing
‘display-buffer’ there followed by 'switch-to-prev-buffer' should get
me to the buffer shown there before TAGS.

Then I could set the default of 'debugger-bury-or-kill' to 'append'
and *Backtrace* would not show up accidentally via
'switch-to-prev-buffer' but still remain on the list of previous
buffers so 'display-buffer-in-previous-window' will find it.  WDYT?

martin


(defcustom switch-to-prev-buffer-skip-regexp
   "\\*Backtrace\\*\\|TAGS"
   "Regexp matching names of buffer `switch-to-prev-buffer' should skip.
The default matches the *Backtrace* and the TAGS buffers."
   :type '(repeat (regexp :format "%v"))
   :group 'windows)

(defun switch-to-prev-buffer (&optional window bury-or-kill)
   "In WINDOW switch to previous buffer.
WINDOW must be a live window and defaults to the selected one.
Return the buffer switched to, nil if no suitable buffer could be
found.

Optional argument BURY-OR-KILL non-nil means the buffer currently
shown in WINDOW is about to be buried or killed and consequently
shall not be switched to in future invocations of this command.

As a special case, if BURY-OR-KILL equals `append', this means to
move the buffer to the end of WINDOW's previous buffers list so a
future invocation of `switch-to-prev-buffer' less likely switches
to it."
   (interactive)
   (let* ((window (window-normalize-window window t))
	 (frame (window-frame window))
          (window-side (window-parameter window 'window-side))
	 (old-buffer (window-buffer window))
	 ;; Save this since it's destroyed by `set-window-buffer'.
	 (next-buffers (window-next-buffers window))
          (pred (frame-parameter frame 'buffer-predicate))
	 entry new-buffer killed-buffers visible)
     (when (window-minibuffer-p window)
       ;; Don't switch in minibuffer window.
       (unless (setq window (minibuffer-selected-window))
	(error "Window %s is a minibuffer window" window)))

     (unless (memq (window-dedicated-p window) '(nil side))
       ;; Don't switch in dedicated window.
       (error "Window %s is dedicated to buffer %s" window old-buffer))

     (catch 'found
       ;; Scan WINDOW's previous buffers first, skipping entries of next
       ;; buffers.
       (dolist (entry (window-prev-buffers window))
	(when (and (setq new-buffer (car entry))
		   (or (buffer-live-p new-buffer)
		       (not (setq killed-buffers
				  (cons new-buffer killed-buffers))))
		   (not (eq new-buffer old-buffer))
                    (not (string-match-p
                          switch-to-prev-buffer-skip-regexp
                          (buffer-name new-buffer)))
                    (or (null pred) (funcall pred new-buffer))
		   ;; When BURY-OR-KILL is nil, avoid switching to a
		   ;; buffer in WINDOW's next buffers list.
		   (or bury-or-kill (not (memq new-buffer next-buffers))))
	  (if (and (not switch-to-visible-buffer)
		   (get-buffer-window new-buffer frame))
	      ;; Try to avoid showing a buffer visible in some other
	      ;; window.
	      (setq visible new-buffer)
	    (set-window-buffer-start-and-point
	     window new-buffer (nth 1 entry) (nth 2 entry))
	    (throw 'found t))))
       ;; Scan reverted buffer list of WINDOW's frame next, skipping
       ;; entries of next buffers.  Note that when we bury or kill a
       ;; buffer we don't reverse the global buffer list to avoid showing
       ;; a buried buffer instead.  Otherwise, we must reverse the global
       ;; buffer list in order to make sure that switching to the
       ;; previous/next buffer traverse it in opposite directions.  Skip
       ;; this step for side windows.
       (unless window-side
         (dolist (buffer (if bury-or-kill
                             (buffer-list frame)
                           (nreverse (buffer-list frame))))
           (when (and (buffer-live-p buffer)
                      (not (eq buffer old-buffer))
                      (not (string-match-p
                            switch-to-prev-buffer-skip-regexp
                            (buffer-name new-buffer)))
                      (or (null pred) (funcall pred buffer))
                      (not (eq (aref (buffer-name buffer) 0) ?\s))
                      ;; Don't show a buffer shown in a side window before.
                      (not (buffer-local-value 'window--sides-shown buffer))
                      (or bury-or-kill (not (memq buffer next-buffers))))
             (if (and (not switch-to-visible-buffer)
                      (get-buffer-window buffer frame))
                 ;; Try to avoid showing a buffer visible in some other window.
                 (unless visible
                   (setq visible buffer))
               (setq new-buffer buffer)
               (set-window-buffer-start-and-point window new-buffer)
               (throw 'found t)))))
       (unless bury-or-kill
	;; Scan reverted next buffers last (must not use nreverse
	;; here!).
	(dolist (buffer (reverse next-buffers))
	  ;; Actually, buffer _must_ be live here since otherwise it
	  ;; would have been caught in the scan of previous buffers.
	  (when (and (or (buffer-live-p buffer)
			 (not (setq killed-buffers
				    (cons buffer killed-buffers))))
		     (not (eq buffer old-buffer))
                      (not (string-match-p
                            switch-to-prev-buffer-skip-regexp
                            (buffer-name new-buffer)))
                      (or (null pred) (funcall pred buffer))
		     (setq entry (assq buffer (window-prev-buffers window))))
	    (setq new-buffer buffer)
	    (set-window-buffer-start-and-point
	     window new-buffer (nth 1 entry) (nth 2 entry))
	    (throw 'found t))))

       ;; Show a buffer visible in another window.
       (when visible
	(setq new-buffer visible)
	(set-window-buffer-start-and-point window new-buffer)))

     (if bury-or-kill
	(let ((entry (and (eq bury-or-kill 'append)
			  (assq old-buffer (window-prev-buffers window)))))
	  ;; Remove `old-buffer' from WINDOW's previous and (restored list
	  ;; of) next buffers.
	  (set-window-prev-buffers
	   window (assq-delete-all old-buffer (window-prev-buffers window)))
	  (set-window-next-buffers window (delq old-buffer next-buffers))
	  (when entry
	    ;; Append old-buffer's entry to list of WINDOW's previous
	    ;; buffers so it's less likely to get switched to soon but
	    ;; `display-buffer-in-previous-window' can nevertheless find
	    ;; it.
	    (set-window-prev-buffers
	     window (append (window-prev-buffers window) (list entry)))))
       ;; Move `old-buffer' to head of WINDOW's restored list of next
       ;; buffers.
       (set-window-next-buffers
        window (cons old-buffer (delq old-buffer next-buffers))))

     ;; Remove killed buffers from WINDOW's previous and next buffers.
     (when killed-buffers
       (dolist (buffer killed-buffers)
	(set-window-prev-buffers
	 window (assq-delete-all buffer (window-prev-buffers window)))
	(set-window-next-buffers
	 window (delq buffer (window-next-buffers window)))))

     ;; Return new-buffer.
     new-buffer))

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> (defcustom switch-to-prev-buffer-skip-regexp
>   "\\*Backtrace\\*\\|TAGS"

Sorry, this list looks too ad-hoc.  And why there is no *Edebug Backtrace*?
*Edebug Backtrace* should be treated exactly the same way as
*Backtrace*, but in practice this means adding a whole bunch
of same variables

debugger-previous-window
debugger-pre-previous-window
debugger-previous-window-height
...

to edebug.el

edebugger-previous-window
edebugger-pre-previous-window
edebugger-previous-window-height
...

and duplicating all related code.  This doesn't look right.

I think that either we should generalize display-buffer-in-previous-window
to avoid such duplication, or better never display temporary buffers
in unrelated windows at all, i.e. to replace display-buffer-in-previous-window
in the action list with display-buffer-below-selected and
display-buffer-at-bottom.

This is exactly what we already do for displaying other temporary
buffers like *Marked Files*, *Completions*, etc.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 >> (defcustom switch-to-prev-buffer-skip-regexp
 >>    "\\*Backtrace\\*\\|TAGS"
 >
 > Sorry, this list looks too ad-hoc.  And why there is no *Edebug Backtrace*?
 > *Edebug Backtrace* should be treated exactly the same way as
 > *Backtrace*, but in practice this means adding a whole bunch
 > of same variables
 >
 > debugger-previous-window
 > debugger-pre-previous-window
 > debugger-previous-window-height
 > ...
 >
 > to edebug.el
 >
 > edebugger-previous-window
 > edebugger-pre-previous-window
 > edebugger-previous-window-height
 > ...
 >
 > and duplicating all related code.  This doesn't look right.
 >
 > I think that either we should generalize display-buffer-in-previous-window
 > to avoid such duplication, or better never display temporary buffers
 > in unrelated windows at all, i.e. to replace display-buffer-in-previous-window
 > in the action list with display-buffer-below-selected and
 > display-buffer-at-bottom.

Pardon me, aren't you confusing 'display-buffer-in-previous-window'
with 'switch-to-prev-buffer' here?  The change I propose doesn't
affect 'display-buffer-in-previous-window' at all.  It simply should
avoid that 'switch-to-prev-buffer' shows such a buffer.  Also, while
'display-buffer-below-selected' and 'display-buffer-at-bottom' usually
do what they are intended to do they may also reuse an existing window
when splitting fails.

 > This is exactly what we already do for displaying other temporary
 > buffers like *Marked Files*, *Completions*, etc.

FWIW most of these are killed immediately after fulfilling their
purpose.  Setting 'debugger-bury-or-kill' to 'kill' would do the same.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> *Edebug Backtrace* should be treated exactly the same way as
>> *Backtrace*, but in practice this means adding a whole bunch
>> of same variables
>>
>> debugger-previous-window
>> debugger-pre-previous-window
>> debugger-previous-window-height
>> ...
>>
>> to edebug.el
>>
>> edebugger-previous-window
>> edebugger-pre-previous-window
>> edebugger-previous-window-height
>> ...
>>
>> and duplicating all related code.  This doesn't look right.
>>
>> I think that either we should generalize display-buffer-in-previous-window
>> to avoid such duplication, or better never display temporary buffers
>> in unrelated windows at all, i.e. to replace display-buffer-in-previous-window
>> in the action list with display-buffer-below-selected and
>> display-buffer-at-bottom.
>
> Pardon me, aren't you confusing 'display-buffer-in-previous-window'
> with 'switch-to-prev-buffer' here?  The change I propose doesn't
> affect 'display-buffer-in-previous-window' at all.  It simply should
> avoid that 'switch-to-prev-buffer' shows such a buffer.  Also, while
> 'display-buffer-below-selected' and 'display-buffer-at-bottom' usually
> do what they are intended to do they may also reuse an existing window
> when splitting fails.

'display-buffer-in-previous-window' searches the buffer in the
prev-buffers list that 'switch-to-prev-buffer' might want to skip
(I still doubt this need).

I proposed to generalize display-buffer-in-previous-window
to avoid duplicating code like in debug.el that uses
debugger-previous-window, debugger-pre-previous-window,
debugger-previous-window-height because the same feature
is needed in other packages like edebug.el.

The same feature is needed also for next-error to display hits
from different buffers in the same window.

Or better to obviate the need in all this complex special handling
simply by removing the get-lru-window rule in the default action,
thus replacing it with get-mru-window.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > 'display-buffer-in-previous-window' searches the buffer in the
 > prev-buffers list that 'switch-to-prev-buffer' might want to skip
 > (I still doubt this need).

The need to skip or the need to search?

 > I proposed to generalize display-buffer-in-previous-window
 > to avoid duplicating code like in debug.el that uses
 > debugger-previous-window, debugger-pre-previous-window,
 > debugger-previous-window-height because the same feature
 > is needed in other packages like edebug.el.
 >
 > The same feature is needed also for next-error to display hits
 > from different buffers in the same window.

When a user can always make a new window there is indeed no problem:
place or reuse the window below the selected window or on the bottom
of the frame.  Both approaches are sufficiently deterministic in their
choice of a window.

But as soon as a window must be reused and the selected one is at the
bottom of the frame, it can become quite difficult to assure that a
buffer shows up in a deterministic location.  This eventually gave
raise to the idea of introducing 'display-buffer-in-previous-window'
(together with the fact that a window's previous buffers then became
easily available via 'window-prev-buffers').

But 'display-buffer-in-previous-window' works only when the buffer is
(1) kept alive while not being displayed and (2) is kept on the list
of a window's previous buffers.  We could add the _names_ of buffers
previously shown to 'window-prev-buffers' but that would not allow for
auto-removing entries when a buffer gets killed and also fail when
buffers are renamed.  So generalizing that function might be
non-trivial.

 > Or better to obviate the need in all this complex special handling
 > simply by removing the get-lru-window rule in the default action,
 > thus replacing it with get-mru-window.

When people work with two windows simultaneously, the mru one is
usually the "other" window they work with, maybe showing the same
buffer at a different location.  I think it would be a bad idea to
punish such users by reusing the other window for showing some
temporary buffer instead.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> 'display-buffer-in-previous-window' searches the buffer in the
>> prev-buffers list that 'switch-to-prev-buffer' might want to skip
>> (I still doubt this need).
>
> The need to skip or the need to search?

The need to skip.  If the original window was too small
to split and display the buffer in a new window below, then
if some existing window is reused to display the temporary buffer,
it's understandable for the user why that temporary buffer is shown
in the window-local tab-bar.

At least, then the user will see in which window the same buffer
will be reappear again - in the same window that shows this buffer
in its window-local tab-bar.

>> I proposed to generalize display-buffer-in-previous-window
>> to avoid duplicating code like in debug.el that uses
>> debugger-previous-window, debugger-pre-previous-window,
>> debugger-previous-window-height because the same feature
>> is needed in other packages like edebug.el.
>>
>> The same feature is needed also for next-error to display hits
>> from different buffers in the same window.
>
> When a user can always make a new window there is indeed no problem:
> place or reuse the window below the selected window or on the bottom
> of the frame.  Both approaches are sufficiently deterministic in their
> choice of a window.

I agree.

> But as soon as a window must be reused and the selected one is at the
> bottom of the frame, it can become quite difficult to assure that a
> buffer shows up in a deterministic location.  This eventually gave
> raise to the idea of introducing 'display-buffer-in-previous-window'
> (together with the fact that a window's previous buffers then became
> easily available via 'window-prev-buffers').

The second time when the buffer is displayed again in a previous window
is deterministic.  But the first time it is non-deterministic - it's
displayed in a random window.  At least, the user can't predict the
window where it will be displayed - thus the surprise factor.
With get-mru-window instead get-lru-window the place is more
deterministic because the user usually remembers which window is mru.

>> Or better to obviate the need in all this complex special handling
>> simply by removing the get-lru-window rule in the default action,
>> thus replacing it with get-mru-window.
>
> When people work with two windows simultaneously, the mru one is
> usually the "other" window they work with, maybe showing the same
> buffer at a different location.  I think it would be a bad idea to
> punish such users by reusing the other window for showing some
> temporary buffer instead.

Right.  Neither lru nor mru should be used to steal existing windows
from users to show temporary buffers.  Only new windows should be
created below or on the bottom.

But my complaint about get-lru-window is that it prevents me from
using more than two windows.  When I create three windows or more,
then get-lru-window always selects a wrong window.  Is it possible
to change get-lru-window to get-mru-window to allow using three windows
and more on the same frame?

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > The need to skip.  If the original window was too small
 > to split and display the buffer in a new window below, then
 > if some existing window is reused to display the temporary buffer,
 > it's understandable for the user why that temporary buffer is shown
 > in the window-local tab-bar.
 >
 > At least, then the user will see in which window the same buffer
 > will be reappear again - in the same window that shows this buffer
 > in its window-local tab-bar.

The latter is a visual feedback.  But if I blindly use C-x left, I'd
still be surprised.

 > The second time when the buffer is displayed again in a previous window
 > is deterministic.  But the first time it is non-deterministic - it's
 > displayed in a random window.  At least, the user can't predict the
 > window where it will be displayed - thus the surprise factor.
 > With get-mru-window instead get-lru-window the place is more
 > deterministic because the user usually remembers which window is mru.

We can add an action alist entry to get the mru (or better
mru-not-selected) behavior.  A small deal.

 >> When people work with two windows simultaneously, the mru one is
 >> usually the "other" window they work with, maybe showing the same
 >> buffer at a different location.  I think it would be a bad idea to
 >> punish such users by reusing the other window for showing some
 >> temporary buffer instead.
 >
 > Right.  Neither lru nor mru should be used to steal existing windows
 > from users to show temporary buffers.  Only new windows should be
 > created below or on the bottom.
 >
 > But my complaint about get-lru-window is that it prevents me from
 > using more than two windows.

... the way you want.

 > When I create three windows or more,
 > then get-lru-window always selects a wrong window.  Is it possible
 > to change get-lru-window to get-mru-window to allow using three windows
 > and more on the same frame?

Earlier we discussed whether "creating a window" should also mean
"using that window".  This could be yet another action alist entry -
bump the use time of the window used for displaying a buffer even when
it's not selected.

I suggest you try adding this and the one providing mru behavior I
mentioned above, experiment with them and install them if they give
good results.

martin

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > I suggest you try adding this and the one providing mru behavior I
 > mentioned above, experiment with them and install them if they give
 > good results.

Something I notoriously forget in all my answers: Note that you need
not add an action function in 'display-buffer-overriding-action' and
friends.  Adding an action alist entry can often be sufficient to
affect the remaining functions in the desired fashion.  I suppose you
knew that already, but just in case ...

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> The need to skip.  If the original window was too small
>> to split and display the buffer in a new window below, then
>> if some existing window is reused to display the temporary buffer,
>> it's understandable for the user why that temporary buffer is shown
>> in the window-local tab-bar.
>>
>> At least, then the user will see in which window the same buffer
>> will be reappear again - in the same window that shows this buffer
>> in its window-local tab-bar.
>
> The latter is a visual feedback.  But if I blindly use C-x left, I'd
> still be surprised.

Then maybe better to add such buffers to the end of the prev-buffers list
or to the end of the next-buffers list.

>> The second time when the buffer is displayed again in a previous window
>> is deterministic.  But the first time it is non-deterministic - it's
>> displayed in a random window.  At least, the user can't predict the
>> window where it will be displayed - thus the surprise factor.
>> With get-mru-window instead get-lru-window the place is more
>> deterministic because the user usually remembers which window is mru.
>
> We can add an action alist entry to get the mru (or better
> mru-not-selected) behavior.  A small deal.

This would be very nice, thanks in advance.

>> When I create three windows or more, then get-lru-window always
>> selects a wrong window.  Is it possible to change get-lru-window to
>> get-mru-window to allow using three windows and more on the
>> same frame?
>
> Earlier we discussed whether "creating a window" should also mean
> "using that window".  This could be yet another action alist entry -
> bump the use time of the window used for displaying a buffer even when
> it's not selected.

It seems the logic in most cases doesn't depend on creation time,
only on usage time like in mru.

> Something I notoriously forget in all my answers: Note that you need
> not add an action function in 'display-buffer-overriding-action' and
> friends.  Adding an action alist entry can often be sufficient to
> affect the remaining functions in the desired fashion.  I suppose you
> knew that already, but just in case ...

I don't understand what an alist entry you mean.  Or you mean adding
a new alist entry like (default-window . mru-not-selected)?

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > Then maybe better to add such buffers to the end of the prev-buffers list
 > or to the end of the next-buffers list.

We have that option in 'debugger-bury-or-kill'.  Do you mean to
generalize it?

 >>> The second time when the buffer is displayed again in a previous window
 >>> is deterministic.  But the first time it is non-deterministic - it's
 >>> displayed in a random window.  At least, the user can't predict the
 >>> window where it will be displayed - thus the surprise factor.
 >>> With get-mru-window instead get-lru-window the place is more
 >>> deterministic because the user usually remembers which window is mru.
 >>
 >> We can add an action alist entry to get the mru (or better
 >> mru-not-selected) behavior.  A small deal.
 >
 > This would be very nice, thanks in advance.

OK.  What do you want to call it, 'windows-to-examine'?  Shall we make
it a list of function/frame pairs defaulting to

'((get-lru-window . nil) (get-largest-window . visible) (get-largest-window . 0))

where nil stands for whatever

(or (window--frame-usable-p (selected-frame))
     (window--frame-usable-p (last-nonminibuffer-frame)))

returns?  Or do you want to control the DEDICATED and NOT-SELECTED
arguments as well?  I hope that 'get-largest-window', 'get-lru-window'
and 'get-mru-window' are 100% compatible wrt their arguments but
haven't verified that yet.

 > I don't understand what an alist entry you mean.  Or you mean adding
 > a new alist entry like (default-window . mru-not-selected)?

For example.  To provide the 'windows-to-examine' sketched above you
wouldn't want to specify an action function too.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> Then maybe better to add such buffers to the end of the prev-buffers list
>> or to the end of the next-buffers list.
>
> We have that option in 'debugger-bury-or-kill'.  Do you mean to
> generalize it?

Yes, it could be moved to a new alist entry.

> OK.  What do you want to call it, 'windows-to-examine'?

Too long name.  Maybe better 'try-windows'?  Or 'reuse-window'
if this alist entry will be used in display-buffer-use-some-window.

> Shall we make it a list of function/frame pairs defaulting to
>
> '((get-lru-window . nil) (get-largest-window . visible) (get-largest-window . 0))
>
> where nil stands for whatever
>
> (or (window--frame-usable-p (selected-frame))
>     (window--frame-usable-p (last-nonminibuffer-frame)))
>
> returns?  Or do you want to control the DEDICATED and NOT-SELECTED
> arguments as well?  I hope that 'get-largest-window', 'get-lru-window'
> and 'get-mru-window' are 100% compatible wrt their arguments but
> haven't verified that yet.

I thought it could be a list of window types to try in the specified order,
for example:

(try-windows . (mru lru largest-visible largest-visible-and-iconified))

>> I don't understand what an alist entry you mean.  Or you mean adding
>> a new alist entry like (default-window . mru-not-selected)?
>
> For example.  To provide the 'windows-to-examine' sketched above you
> wouldn't want to specify an action function too.

But where this alist entry should be customized for all action functions?
I guess not in display-buffer-alist that specifies specific buffers.
Then where?  Maybe, in display-buffer-base-action with nil action and
non-nil alist that will be the default alist for all actions?

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 >>> Then maybe better to add such buffers to the end of the prev-buffers list
 >>> or to the end of the next-buffers list.
 >>
 >> We have that option in 'debugger-bury-or-kill'.  Do you mean to
 >> generalize it?
 >
 > Yes, it could be moved to a new alist entry.

And act like a time-bomb via a window-parameter (like 'quit-restore')?

 >> OK.  What do you want to call it, 'windows-to-examine'?
 >
 > Too long name.  Maybe better 'try-windows'?  Or 'reuse-window'
 > if this alist entry will be used in display-buffer-use-some-window.

'try-windows' sounds too active for an alist entry - we would have to
use 'windows-to-try' instead.  And let's avoid 'reuse-window' in this
context - it's too ambiguous.  BTW we might also want to add a similar
entry for specifying the window we want to split (which means we could
easily generalize 'display-buffer-below-selected' and
'display-buffer-at-bottom' without having to add new action functions
like 'display-buffer-at-top' ...) and should reserve an appropriate
name for that.

 >> Shall we make it a list of function/frame pairs defaulting to
 >>
 >> '((get-lru-window . nil) (get-largest-window . visible) (get-largest-window . 0))
 >>
 >> where nil stands for whatever
 >>
 >> (or (window--frame-usable-p (selected-frame))
 >>      (window--frame-usable-p (last-nonminibuffer-frame)))
 >>
 >> returns?  Or do you want to control the DEDICATED and NOT-SELECTED
 >> arguments as well?  I hope that 'get-largest-window', 'get-lru-window'
 >> and 'get-mru-window' are 100% compatible wrt their arguments but
 >> haven't verified that yet.
 >
 > I thought it could be a list of window types to try in the specified order,
 > for example:
 >
 > (try-windows . (mru lru largest-visible largest-visible-and-iconified))

... and lru-visible, lru-invisible?  BTW we could allow it to specify
using windows dedicated to another buffer as well.

 >>> I don't understand what an alist entry you mean.  Or you mean adding
 >>> a new alist entry like (default-window . mru-not-selected)?
 >>
 >> For example.  To provide the 'windows-to-examine' sketched above you
 >> wouldn't want to specify an action function too.
 >
 > But where this alist entry should be customized for all action functions?
 > I guess not in display-buffer-alist that specifies specific buffers.
 > Then where?  Maybe, in display-buffer-base-action with nil action and
 > non-nil alist that will be the default alist for all actions?

Anywhere.  Why should we impose any restrictions here - either for the
user or for the application programmer?

martin

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 >>>>> Then maybe better to add such buffers to the end of the
 >>>>> prev-buffers list or to the end of the next-buffers list.
 >>>>
 >>>> We have that option in 'debugger-bury-or-kill'.  Do you mean to
 >>>> generalize it?
 >>>
 >>> Yes, it could be moved to a new alist entry.
 >>
 >> And act like a time-bomb via a window-parameter (like 'quit-restore')?
 >
 > I don't understand what would happen with this.

An alist entry describes what should happen at the time a buffer is
shown.  'debugger-bury-or-kill' describes what should happen when a
buffer is unshown, something which may happen long after showing it.
So we have to remember the thing to do at unshow time (probably in a
window parameter) and make the unshow code aware of it when it runs.

 >> 'try-windows' sounds too active for an alist entry - we would have to
 >> use 'windows-to-try' instead.
 >
 > If you want more declarative names, then what about 'candidates' or
 > 'default-window'.

Both could apply to any action function: I'd prefer something that can
be attached to specific action function like 'windows-to-use' or
'some-windows' for 'display-buffer-use-some-window' and
'windows-to-split' or 'pop-up-from' for 'display-buffer-pop-up-window'.

 >> BTW we might also want to add a similar entry for specifying the
 >> window we want to split (which means we could easily generalize
 >> 'display-buffer-below-selected' and 'display-buffer-at-bottom' without
 >> having to add new action functions like 'display-buffer-at-top' ...)
 >> and should reserve an appropriate name for that.
 >
 > Maybe use names like in WindMove: action 'display-buffer-in-direction'
 > and an alist entry '(dir . right)' where the default is '(dir . below)'

For example.  The question is whether any such 'dir' should apply to
using, splitting or both.  That's why I'd rather include the direction
separately in the 'windows-to-use' and 'windows-to-split' entries or
whatever we call them.

That is we have to decide whether we make one entry dedicated to each
buffer display function or make entries that apply to more than one
such function.  We have the latter already for the 'side' entry and
I'm not sure whether I like it because it's not always clear whether
two action functions are mutually exclusive: Now hardly anyone would
ever want to _facultatively_ display a buffer in a side window or an
atomic window.  But when we want 'side' to refer to where a new window
should be created or (re-)used I'm not entirely sure.  I know that
'display-buffer-below-selected' and 'display-buffer-at-bottom' both
implicitly fix the side (or direction) for both, using and splitting,
and that's OK but maybe not all applications might want it.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> An alist entry describes what should happen at the time a buffer is
> shown.  'debugger-bury-or-kill' describes what should happen when a
> buffer is unshown, something which may happen long after showing it.
> So we have to remember the thing to do at unshow time (probably in a
> window parameter) and make the unshow code aware of it when it runs.

I imagine a list of prev/next-buffers as the tab-bar:

[buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E]
prev-buffers          current-buffer      next-buffers

Using switch-to-buffer adds a new buffer after the current "tab", e.g.

[buffer-A] [buffer-B] [buffer-C] [new-buffer] [buffer-D] [buffer-E]
prev-buffers                  current-buffer           next-buffers

But displaying a temporary buffer could add a "tab" to the end of the
tab-bar, this means at the end of the list of next-buffers:

[buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer]
prev-buffers                                         current-buffer

After exiting from this temporary buffer, it could be kept in the
list of next-buffers:

[buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer]
prev-buffers          current-buffer                    next-buffers

Then returning to prev-buffers (e.g. with kill-buffer) will not visit
this temporary buffer.  But display-buffer-reuse-window could look for
a previously displayed buffer in the list of next buffers.

> That is we have to decide whether we make one entry dedicated to each
> buffer display function or make entries that apply to more than one
> such function.  We have the latter already for the 'side' entry and
> I'm not sure whether I like it because it's not always clear whether
> two action functions are mutually exclusive: Now hardly anyone would
> ever want to _facultatively_ display a buffer in a side window or an
> atomic window.  But when we want 'side' to refer to where a new window
> should be created or (re-)used I'm not entirely sure.  I know that
> 'display-buffer-below-selected' and 'display-buffer-at-bottom' both
> implicitly fix the side (or direction) for both, using and splitting,
> and that's OK but maybe not all applications might want it.

We could have a general shorter name like 'dir', and more specific
longer names like 'select-dir' and 'split-dir'.  If no long entries
are found, then fall back to a shorter name.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > I imagine a list of prev/next-buffers as the tab-bar:
 >
 > [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E]
 > prev-buffers          current-buffer      next-buffers
 >
 > Using switch-to-buffer adds a new buffer after the current "tab", e.g.
 >
 > [buffer-A] [buffer-B] [buffer-C] [new-buffer] [buffer-D] [buffer-E]
 > prev-buffers                  current-buffer           next-buffers

So far the buffer shown by a window does not appear in its lists of
previous or next buffers.

 > But displaying a temporary buffer could add a "tab" to the end of the
 > tab-bar, this means at the end of the list of next-buffers:
 >
 > [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer]
 > prev-buffers                                         current-buffer

The problem with this approach is as follows: The list of next buffers
is usually empty because it contains only the buffers visited while
navigating the list of previous buffers backwards in time.  It's main
purpose is to revert any overshooting during such navigation.  But
this means that when you add your temporary buffer to the (usually
empty) list of next buffers, overshooting while reverting the
overshooting will get you to that temporary buffer immediately.

In your example I would first show buffer-C then overshoot and show
buffer-B.  Reverting that gets me to buffer-C and overshooting once
more will get me new-buffer immediately (because buffer-D and buffer-E
typically do not exist).

 > After exiting from this temporary buffer, it could be kept in the
 > list of next-buffers:
 >
 > [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer]
 > prev-buffers          current-buffer                    next-buffers
 >
 > Then returning to prev-buffers (e.g. with kill-buffer) will not visit
 > this temporary buffer.  But display-buffer-reuse-window could look for
 > a previously displayed buffer in the list of next buffers.

The main purpose of a window's list of next buffers is that of undoing
a 'switch-to-prev-buffer' step.  I have no idea which consequences
your proposal could have apart from the one I sketched above.  I'm
already no great friend of

      If there is no recent invocation of `switch-to-prev-buffer' that
      can be undone, this function tries to show a buffer from the
      buffer list of the frame WINDOW appears on ...

but this comes from an attempt to model buffer switching like 'undo'
does.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> But displaying a temporary buffer could add a "tab" to the end of the
>> tab-bar, this means at the end of the list of next-buffers:
>>
>> [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer]
>> prev-buffers                                         current-buffer
>
> The problem with this approach is as follows: The list of next buffers
> is usually empty because it contains only the buffers visited while
> navigating the list of previous buffers backwards in time.  It's main
> purpose is to revert any overshooting during such navigation.  But
> this means that when you add your temporary buffer to the (usually
> empty) list of next buffers, overshooting while reverting the
> overshooting will get you to that temporary buffer immediately.

What buffer does it show now in this case?  Is it a more predictable
buffer than would be in case of a previously displayed temporary buffer?

>> After exiting from this temporary buffer, it could be kept in the
>> list of next-buffers:
>>
>> [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer]
>> prev-buffers          current-buffer                    next-buffers
>>
>> Then returning to prev-buffers (e.g. with kill-buffer) will not visit
>> this temporary buffer.  But display-buffer-reuse-window could look for
>> a previously displayed buffer in the list of next buffers.
>
> The main purpose of a window's list of next buffers is that of undoing
> a 'switch-to-prev-buffer' step.  I have no idea which consequences
> your proposal could have apart from the one I sketched above.  I'm
> already no great friend of
>
>      If there is no recent invocation of `switch-to-prev-buffer' that
>      can be undone, this function tries to show a buffer from the
>      buffer list of the frame WINDOW appears on ...

And this is usually some random unpredictable buffer.

> but this comes from an attempt to model buffer switching like 'undo'
> does.

undo/redo is a good analogy.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 >> The problem with this approach is as follows: The list of next buffers
 >> is usually empty because it contains only the buffers visited while
 >> navigating the list of previous buffers backwards in time.  It's main
 >> purpose is to revert any overshooting during such navigation.  But
 >> this means that when you add your temporary buffer to the (usually
 >> empty) list of next buffers, overshooting while reverting the
 >> overshooting will get you to that temporary buffer immediately.
 >
 > What buffer does it show now in this case?  Is it a more predictable
 > buffer than would be in case of a previously displayed temporary buffer?

Currently we remove the buffer in question (*Backtrace*) entirely from
all buffer lists so it isn't found by the switch-to-prev/next-buffer
routines, the list of next buffers is usually empty and it will do ...

 >>       If there is no recent invocation of `switch-to-prev-buffer' that
 >>       can be undone, this function tries to show a buffer from the
 >>       buffer list of the frame WINDOW appears on ...
 >
 > And this is usually some random unpredictable buffer.

Correct.  But we cannot well go to the end of the list of previous
buffers instead.  That list could be even empty.  And traditionally
Emacs chooses some random buffer here although the order is a bit
determined by previous 'bury-buffer' calls.

 >> but this comes from an attempt to model buffer switching like 'undo'
 >> does.
 >
 > undo/redo is a good analogy.

Unfortunately, undo/redo does not stop either where my intuition would
want it.  In particular, I can't tell it to "now redo things until
you've got me back the state with the maximum of changes of the
existing code since I started editing this".  There's some fuzziness
missing.  Maybe some snapshots of my past editing activity ...

martin

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > This is easy to fix, but I'm not sure if this might break some packages
 > that depend on TAGS buffers with original names.

That's what I thought too.

 > Maybe better to represent a list of prev/next buffers as a tree?
 > Then inserting a new buffer inside it will create a leaf that
 > can be ignored for navigation.  An analogy of this is undo-tree.

But then 'display-buffer-in-previous-window' would have to navigate a
tree and I would like to not make it too complicated because it may
have to consider "some" windows as possible candidates.
'switch-to-prev-buffer' OTOH has only one candidate window and can be
made a bit more complicated, if necessary.

martin

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

 > So please think of any bad consequences of what we decide in (1) like
 > not using _any_ window on the selected frame because none of them fits
 > the 'min-height' constraint.  Consider a default two windows frame
 > where the size of the selected window is preserved.

We should be also able to fix Bug#10186 then.

BTW, I recently tried to write a function that can be used to return
the specifics of the window chosen by 'display-buffer'.  Discussions
of the use of such a function were frequent in the past (bug numbers
6000, 10127, 10600, 12618, 17809) but we never came to a conclusion of
whether such a thing would be really useful or can be practically
implemented at all.

Have a look at the patch I attach, it's against the release branch.

martin


[-- Attachment #2: display-buffer-pretend.el --]
[-- Type: application/emacs-lisp, Size: 7740 bytes --]

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> So please think of any bad consequences of what we decide in (1) like
>> not using _any_ window on the selected frame because none of them fits
>> the 'min-height' constraint.  Consider a default two windows frame
>> where the size of the selected window is preserved.
>
> We should be also able to fix Bug#10186 then.
>
> BTW, I recently tried to write a function that can be used to return
> the specifics of the window chosen by 'display-buffer'.  Discussions
> of the use of such a function were frequent in the past (bug numbers
> 6000, 10127, 10600, 12618, 17809) but we never came to a conclusion of
> whether such a thing would be really useful or can be practically
> implemented at all.
>
> Have a look at the patch I attach, it's against the release branch.

If I understand correctly the purpose of your function, maybe a better
name would be display-buffer-try?  Or if it also checks some predefined
values, then maybe display-buffer-assert?

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > If I understand correctly the purpose of your function, maybe a better
 > name would be display-buffer-try?  Or if it also checks some predefined
 > values, then maybe display-buffer-assert?

We already have 'display-buffer-try', we call it 'display-buffer'.
This one would then be better called 'display-buffer-try-and-revert'
or maybe 'display-buffer-invisibly'.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> If I understand correctly the purpose of your function, maybe a better
>> name would be display-buffer-try?  Or if it also checks some predefined
>> values, then maybe display-buffer-assert?
>
> We already have 'display-buffer-try', we call it 'display-buffer'.
> This one would then be better called 'display-buffer-try-and-revert'
> or maybe 'display-buffer-invisibly'.

This resembles more with-like functions such as with-selected-frame
and with-selected-window.  Maybe then call it with-display-buffer
or with-displayed-buffer.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > This resembles more with-like functions such as with-selected-frame
 > and with-selected-window.  Maybe then call it with-display-buffer
 > or with-displayed-buffer.

'with-buffer-displayed' maybe.  Although it's questionable whether an
invisible frame actually displays something.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> This resembles more with-like functions such as with-selected-frame
>> and with-selected-window.  Maybe then call it with-display-buffer
>> or with-displayed-buffer.
>
> 'with-buffer-displayed' maybe.  Although it's questionable whether an
> invisible frame actually displays something.

Isn't this bad that this function does the double work, i.e.
first displays the buffer, then reverts, and if everything is right,
displays the same buffer again.  Shouldn't it display the buffer
only once, then check if everything is right, and revert only
if not.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > Isn't this bad that this function does the double work, i.e.
 > first displays the buffer, then reverts, and if everything is right,
 > displays the same buffer again.  Shouldn't it display the buffer
 > only once, then check if everything is right, and revert only
 > if not.

The primal problem this was supposed to solve is:

(1) Get the size (typically the body width) of the window supposed to
     display a buffer (typically a doc or man buffer).

(2) Format the buffer in some way so that it fits into (1)'s size.

(3) Call 'display-buffer' to actually display the buffer.

In such a scenario the time to perform (2) usually dwarfs the time
needed by (1) so it shouldn't be that bad.

We obviously could use this approach to revert 'display-buffer'
whenever it did something bad.  But we shouldn't do that by default,
the overhead for storing the configurations is not negligible.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> Isn't this bad that this function does the double work, i.e.
>> first displays the buffer, then reverts, and if everything is right,
>> displays the same buffer again.  Shouldn't it display the buffer
>> only once, then check if everything is right, and revert only
>> if not.
>
> The primal problem this was supposed to solve is:
>
> (1) Get the size (typically the body width) of the window supposed to
>     display a buffer (typically a doc or man buffer).
>
> (2) Format the buffer in some way so that it fits into (1)'s size.
>
> (3) Call 'display-buffer' to actually display the buffer.

This is why man.el currently uses a simpler solution:

(1) Call 'display-buffer' to display the buffer.

(2) Format the buffer in some way so that it fits into displayed size.

> We obviously could use this approach to revert 'display-buffer'
> whenever it did something bad.  But we shouldn't do that by default,
> the overhead for storing the configurations is not negligible.

When a man page is not found, currently it reverts 'display-buffer'.

What benefits would be provided by the approach that uses
'display-buffer-try-and-revert'?

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > This is why man.el currently uses a simpler solution:
 >
 > (1) Call 'display-buffer' to display the buffer.
 >
 > (2) Format the buffer in some way so that it fits into displayed size.

And I always agreed on that.  But IIUC this approach was not applied
on all bugs whose numbers I previously mentioned.

 > When a man page is not found, currently it reverts 'display-buffer'.

Can that be annoying in practice?

 > What benefits would be provided by the approach that uses
 > 'display-buffer-try-and-revert'?

None probably.  We could build into it some trickery (to not revert
the configuration or make a new frame visible under certain
conditions) but I doubt this would work out very well in all cases.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> When a man page is not found, currently it reverts 'display-buffer'.
>
> Can that be annoying in practice?

Not annoying because it reverts 'display-buffer' immediately after invocation,
not later.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 >>> When a man page is not found, currently it reverts 'display-buffer'.
 >>
 >> Can that be annoying in practice?
 >
 > Not annoying because it reverts 'display-buffer' immediately after invocation,
 > not later.

What does "revert" mean in practice?  For example, what happens when
'display-buffer' would make a new frame?  Would it "revert" before
that?

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> What does "revert" mean in practice?  For example, what happens when
> 'display-buffer' would make a new frame?  Would it "revert" before
> that?

Yes, it reverts making a new frame, i.e. deletes the frame.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 >> What does "revert" mean in practice?  For example, what happens when
 >> 'display-buffer' would make a new frame?  Would it "revert" before
 >> that?
 >
 > Yes, it reverts making a new frame, i.e. deletes the frame.

Can you point me at the respective code?

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>>> What does "revert" mean in practice?  For example, what happens when
>>> 'display-buffer' would make a new frame?  Would it "revert" before
>>> that?
>>
>> Yes, it reverts making a new frame, i.e. deletes the frame.
>
> Can you point me at the respective code?

Please see quit-restore-window in Man-bgproc-sentinel.
It should delete a window and its frame.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 >>> Yes, it reverts making a new frame, i.e. deletes the frame.
 >>
 >> Can you point me at the respective code?
 >
 > Please see quit-restore-window in Man-bgproc-sentinel.
 > It should delete a window and its frame.

Thanks.  How does this perform in practice?  Don't you see some flicker
when deleting the frame?

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>>>> Yes, it reverts making a new frame, i.e. deletes the frame.
>>>
>>> Can you point me at the respective code?
>>
>> Please see quit-restore-window in Man-bgproc-sentinel.
>> It should delete a window and its frame.
>
> Thanks.  How does this perform in practice?  Don't you see some flicker
> when deleting the frame?

Indeed, some flicker when a man page is not found.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 >> Don't you see some flicker
 >> when deleting the frame?
 >
 > Indeed, some flicker when a man page is not found.

When I delete an _invisible_ frame, I see some flicker too.  I wonder
what's causing it.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>>> Don't you see some flicker when deleting the frame?
>>
>> Indeed, some flicker when a man page is not found.
>
> When I delete an _invisible_ frame, I see some flicker too.  I wonder
> what's causing it.

You mean there is flicker even in display-buffer-pretend?

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > You mean there is flicker even in display-buffer-pretend?

Here on Windows, yes.  I think it's either a window manager or desktop
issue.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> So you mean that if Emacs can't fulfill a 'window-height' contract for
> a new window below the selected one, it shouldn't make a new one in
> the first place?  Then with an an alist entry called 'min-height' we
> could rewrite 'display-buffer-below-selected' as follows:

Another reason why this urgently needs to be fixed using
'display-buffer-below-selected' with 'window-height' is that
for example visiting a gpg file that fails to decrypt displays
the *Backtrace* buffer with (file-error "Opening input file" "Can't decrypt"
in another window that hides another essential buffer *Error*
(with explanation of the error raised while decrypting)
displayed in the same window.  But using 'display-buffer-below-selected'
both essential buffers will be displayed in separate windows.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > Another reason why this urgently needs to be fixed using
 > 'display-buffer-below-selected' with 'window-height' is that
 > for example visiting a gpg file that fails to decrypt displays
 > the *Backtrace* buffer with (file-error "Opening input file" "Can't decrypt"
 > in another window that hides another essential buffer *Error*
 > (with explanation of the error raised while decrypting)
 > displayed in the same window.  But using 'display-buffer-below-selected'
 > both essential buffers will be displayed in separate windows.

So what should we do?  I earlier proposed a 'min-height' entry like in
the code below.  Would that suffice?  If so, would we use the same for
'display-buffer-pop-up-window' and 'display-buffer-at-bottom'?  Should
we check the window below (if we "use" but do not "reuse" it) if it's
high enough?  I think we should provide exact semantics for any such
'min-height' entry so we can easily tell which action functions should
check it.

(defun display-buffer-below-selected (buffer alist)
   "Try displaying BUFFER in a window below the selected window.
If there is a window below the selected one and that window
already displays BUFFER, use that window.  Otherwise, try to
create a new window below the selected one and show BUFFER there.
If that attempt fails as well and there is a non-dedicated window
below the selected one, use that window."
   (let ((min-height (cdr (assq 'min-height alist)))
     window)
     (or (and (setq window (window-in-direction 'below))
          (eq buffer (window-buffer window))
          (window--display-buffer buffer window 'reuse alist))
     (and (not (frame-parameter nil 'unsplittable))
          (or (not (numberp min-height))
          (window-sizable-p nil (- min-height)))
          (let ((split-height-threshold 0)
            split-width-threshold)
            (setq window (window--try-to-split-window
                              (selected-window) alist)))
          (window--display-buffer
           buffer window 'window alist display-buffer-mark-dedicated))
     (and (setq window (window-in-direction 'below))
          (not (window-dedicated-p window))
          (window--display-buffer
           buffer window 'reuse alist display-buffer-mark-dedicated)))))

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> Another reason why this urgently needs to be fixed using
>> 'display-buffer-below-selected' with 'window-height' is that
>> for example visiting a gpg file that fails to decrypt displays
>> the *Backtrace* buffer with (file-error "Opening input file" "Can't decrypt"
>> in another window that hides another essential buffer *Error*
>> (with explanation of the error raised while decrypting)
>> displayed in the same window.  But using 'display-buffer-below-selected'
>> both essential buffers will be displayed in separate windows.
>
> So what should we do?  I earlier proposed a 'min-height' entry like in
> the code below.

Thanks, I tried and it works well.

> Would that suffice?  If so, would we use the same for
> 'display-buffer-pop-up-window' and 'display-buffer-at-bottom'?

I don't know about display-buffer-pop-up-window, but for
display-buffer-at-bottom where the height depends on the
number of lines in the displayed buffer like e.g. *Completions*
this is not needed.

> Should we check the window below (if we "use" but do not "reuse" it)
> if it's high enough?  I think we should provide exact semantics for
> any such 'min-height' entry so we can easily tell which action
> functions should check it.

I think the semantics of 'min-height' should be a minimal height
of the displayed window wherever it can be displayed.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]

 >> Would that suffice?  If so, would we use the same for
 >> 'display-buffer-pop-up-window' and 'display-buffer-at-bottom'?
 >
 > I don't know about display-buffer-pop-up-window, but for
 > display-buffer-at-bottom where the height depends on the
 > number of lines in the displayed buffer like e.g. *Completions*
 > this is not needed.

Note that 'display-buffer-at-bottom' is agnostic of the number of
lines in the displayed buffer.

We eventually need a generally applicable rule because the user might
want to add such an entry to 'display-buffer-alist'.  And we might
want a corresponding width entry for symmetry.  For the moment, we can
say that the entry is handled by 'display-buffer-below-selected' only.
In the attached two functions I renamed it to 'window-min-height' to
make it more consistent with 'window-height'.  Please have a look.

 > I think the semantics of 'min-height' should be a minimal height
 > of the displayed window wherever it can be displayed.

To amend the remaining buffer display action functions, a substantial
number of changes will have to be made.  'window-splittable-p', for
example, would need an additional MIN-SIZE argument.  And what about
'display-buffer-same-window' or 'display-buffer-in-previous-window'?

martin

[-- Attachment #2: window--ensure-min-size.el --]
[-- Type: application/emacs-lisp, Size: 2297 bytes --]

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

 > In the attached two functions I renamed it to 'window-min-height' to
 > make it more consistent with 'window-height'.  Please have a look.

Please do not have a look at that.  It does things it shouldn't do;
ignoring OT1H and messing up OTOH the 'quit-restore' parameter of the
(re-)used window.

Please try the now attached version of 'display-buffer-below-selected'
instead.  The idea is that when you call

(display-buffer-below-selected BUFFER '((window-min-height . 40)))

it makes sure that the window used has at least 40 lines or can be
resized to 40 lines at least.  To really make the window 40 lines tall
you have to use 'window-height' too, like

(display-buffer-below-selected
   BUFFER '((window-min-height . 40) (window-height . 40)))

Obviously, 'window-height' may have a different value than 40 and
'display-buffer' will then try to use that value if it is allowed to
do so.  This means that

(display-buffer-below-selected
   BUFFER '((window-min-height . 40) (window-height . 20)))

may fail if the window can be made 20 lines tall but not 40.  But if
the window can be made 40 lines tall 'display-buffer-below-selected'
will try to make it 20 lines tall.  OTOH

(display-buffer-below-selected
   BUFFER '((window-min-height . 40) (window-height . 60)))

will fail only if no 40 line tall window can be found or made.  If
subsequent resizing to 60 lines fails, the window will stick to the
preexisting height (which can be the result of a split).

Is that all sufficiently comprehensible and coherent?

martin

[-- Attachment #2: display-buffer-below-selected.el --]
[-- Type: application/emacs-lisp, Size: 2041 bytes --]

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> Is that all sufficiently comprehensible and coherent?

Thanks, I tried and everything makes sense.

What values of window-min-height and window-height would you recommend
for the *Backtrace* buffer's window?  Should we set only window-min-height
to e.g. 10 lines tall, or also window-height?  I'd like to see how this
design applies in practice.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > What values of window-min-height and window-height would you recommend
 > for the *Backtrace* buffer's window?  Should we set only window-min-height
 > to e.g. 10 lines tall, or also window-height?  I'd like to see how this
 > design applies in practice.

'window-min-height' would have the value you had in mind originally.
'window-height' could be the same but this might be too rigid.  IIUC
'debug' first displays the buffer and only afterwards inserts its
text.  If you can change that, try to use 'fit-window-to-buffer' as
'window-height' value.  Otherwise, 'debug' can always call
'fit-window-to-buffer' separately after it has inserted its text.

But please keep in mind that 'display-buffer' can always split a small
(say ten lines) window that is alone on its frame or when the user has
made a special alist entry for it.  Hence 'debug' cannot rely on the
fact that the window produced by 'display-buffer' indeed has or can
have 'window-min-height' lines.  That guarantee is only provided by
'display-buffer-below-selected' (with my current proposal).

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> What values of window-min-height and window-height would you recommend
>> for the *Backtrace* buffer's window?  Should we set only window-min-height
>> to e.g. 10 lines tall, or also window-height?  I'd like to see how this
>> design applies in practice.
>
> 'window-min-height' would have the value you had in mind originally.
> 'window-height' could be the same but this might be too rigid.  IIUC
> 'debug' first displays the buffer and only afterwards inserts its
> text.  If you can change that, try to use 'fit-window-to-buffer' as
> 'window-height' value.  Otherwise, 'debug' can always call
> 'fit-window-to-buffer' separately after it has inserted its text.
>
> But please keep in mind that 'display-buffer' can always split a small
> (say ten lines) window that is alone on its frame or when the user has
> made a special alist entry for it.  Hence 'debug' cannot rely on the
> fact that the window produced by 'display-buffer' indeed has or can
> have 'window-min-height' lines.  That guarantee is only provided by
> 'display-buffer-below-selected' (with my current proposal).

I tried to add actions 'display-buffer-below-selected' and
'display-buffer-at-bottom' with alist (window-min-height . 10)
to your debugger-previous-window patch, and it works well.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > I tried to add actions 'display-buffer-below-selected' and
 > 'display-buffer-at-bottom' with alist (window-min-height . 10)
 > to your debugger-previous-window patch, and it works well.

'display-buffer-at-bottom' doesn't respect 'window-min-height' yet.
If you want it to do that, please tell me.

martin

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > Thanks, I tried and everything makes sense.

Now installed on master.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> Now installed on master.

Thanks.  Do you plan to install emacs-lisp/debug.el as well?

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

 >> Now installed on master.
 >
 > Thanks.  Do you plan to install emacs-lisp/debug.el as well?

Like in the attached patch?  That means to leave the responsibility of
setting ‘window-min-height’ to the user.  If you have anything better
please install that.

martin

[-- Attachment #2: debug.el.diff --]
[-- Type: text/plain, Size: 530 bytes --]

diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
index 34a2a13..f527dc8 100644
--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -239,7 +239,8 @@ debug
 	      (pop-to-buffer
 	       debugger-buffer
 	       `((display-buffer-reuse-window
-		  display-buffer-in-previous-window)
+		  display-buffer-in-previous-window
+                  display-buffer-below-selected)
 		 . (,(when (and (window-live-p debugger-previous-window)
 				(frame-visible-p
 				 (window-frame debugger-previous-window)))

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

> Like in the attached patch?  That means to leave the responsibility of
> setting ‘window-min-height’ to the user.  If you have anything better
> please install that.

Michael, you proposed to use window-min-height in *Backtrace* window.
Do you think it should have some value by default?

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Michael, you proposed to use window-min-height in *Backtrace* window.
> Do you think it should have some value by default?

Would that be a hardcoded value, or do we speak about a new user option?

Michael.

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> Michael, you proposed to use window-min-height in *Backtrace* window.
>> Do you think it should have some value by default?
>
> Would that be a hardcoded value, or do we speak about a new user option?

I don't think that someone might want to customize min-height of *Backtrace*
because its height depends on the call stack depth.

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> > Would that be a hardcoded value, or do we speak about a new user
> > option?
>
> I don't think that someone might want to customize min-height of
> *Backtrace* because its height depends on the call stack depth.

But some people might care and others not because they prefer to resize
the window they get no matter how narrow it is.

If I say the default min height should be 10, could people still
configure otherwise?  Maybe some people could manage with less, because
they use text-scale-mode to use a tinier font or something like that.
Dunno, it's hard to predict.


Michael.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > If I say the default min height should be 10, could people still
 > configure otherwise?

Via 'default-frame-alist', yes.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> If I say the default min height should be 10, could people still
>> configure otherwise?
>
> Via 'default-frame-alist', yes.

I installed display-buffer-below-selected with window-min-height=10.

Please note that if there is no suitable window with at least 10 lines high,
it still displays the *Backtrace* buffer in random windows, every time
in another window because it doesn't remember a previous window.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 617 bytes --]

 > Please note that if there is no suitable window with at least 10 lines high,
 > it still displays the *Backtrace* buffer in random windows, every time
 > in another window because it doesn't remember a previous window.

For starters, users can customize the number of lines by supplying a
'window-min-height' entry.  They can also provide an additional action
function like 'display-buffer-below-selected' as fallback.  And
finally we could try what I suggested earlier: Fill the *Backtrace*
buffer first and pop to it afterwards using 'fit-window-to-buffer'.
The attached untested patch tries to do that.

martin

[-- Attachment #2: debug.diff --]
[-- Type: text/plain, Size: 2438 bytes --]

diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
index b6b1f20..5c186f7 100644
--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -236,12 +236,33 @@ debug
 		;; Place an extra debug-on-exit for macro's.
 		(when (eq 'lambda (car-safe (cadr (backtrace-frame 4))))
 		  (backtrace-debug 5 t)))
+              (with-current-buffer debugger-buffer
+                (unless (derived-mode-p 'debugger-mode)
+	          (debugger-mode))
+	        (debugger-setup-buffer debugger-args))
+	      (when noninteractive
+		;; If the backtrace is long, save the beginning
+		;; and the end, but discard the middle.
+		(when (> (count-lines (point-min) (point-max))
+			 debugger-batch-max-lines)
+		  (goto-char (point-min))
+		  (forward-line (/ 2 debugger-batch-max-lines))
+		  (let ((middlestart (point)))
+		    (goto-char (point-max))
+		    (forward-line (- (/ 2 debugger-batch-max-lines)
+				     debugger-batch-max-lines))
+		    (delete-region middlestart (point)))
+		  (insert "...\n"))
+		(goto-char (point-min))
+		(message "%s" (buffer-string))
+		(kill-emacs -1))
 	      (pop-to-buffer
 	       debugger-buffer
 	       `((display-buffer-reuse-window
 		  display-buffer-in-previous-window
 		  display-buffer-below-selected)
 		 . ((window-min-height . 10)
+                    (window-height . fit-window-to-buffer)
 		    ,@(when (and (window-live-p debugger-previous-window)
 				(frame-visible-p
 				 (window-frame debugger-previous-window)))
@@ -258,25 +279,6 @@ debug
 			    (window-total-height debugger-window)))
 		      (error nil)))
 		(setq debugger-previous-window debugger-window))
-              (unless (derived-mode-p 'debugger-mode)
-	        (debugger-mode))
-	      (debugger-setup-buffer debugger-args)
-	      (when noninteractive
-		;; If the backtrace is long, save the beginning
-		;; and the end, but discard the middle.
-		(when (> (count-lines (point-min) (point-max))
-			 debugger-batch-max-lines)
-		  (goto-char (point-min))
-		  (forward-line (/ 2 debugger-batch-max-lines))
-		  (let ((middlestart (point)))
-		    (goto-char (point-max))
-		    (forward-line (- (/ 2 debugger-batch-max-lines)
-				     debugger-batch-max-lines))
-		    (delete-region middlestart (point)))
-		  (insert "...\n"))
-		(goto-char (point-min))
-		(message "%s" (buffer-string))
-		(kill-emacs -1))
 	      (message "")
 	      (let ((standard-output nil)
 		    (buffer-read-only t))

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> Please note that if there is no suitable window with at least 10 lines high,
>> it still displays the *Backtrace* buffer in random windows, every time
>> in another window because it doesn't remember a previous window.
>
> For starters, users can customize the number of lines by supplying a
> 'window-min-height' entry.  They can also provide an additional action
> function like 'display-buffer-below-selected' as fallback.  And
> finally we could try what I suggested earlier: Fill the *Backtrace*
> buffer first and pop to it afterwards using 'fit-window-to-buffer'.
> The attached untested patch tries to do that.

Thanks, this is much better.

Maybe then window-min-height should be dynamically calculated like

(window-min-height . ,(with-current-buffer debugger-buffer (count-lines (point-min) (point-max))))

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > Maybe then window-min-height should be dynamically calculated like
 >
 > (window-min-height . ,(with-current-buffer debugger-buffer (count-lines (point-min) (point-max))))

Wouldn't this prevent larger *Backtrace* buffers from getting shown
below the selected window?

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> Maybe then window-min-height should be dynamically calculated like
>>
>> (window-min-height . ,(with-current-buffer debugger-buffer (count-lines (point-min) (point-max))))
>
> Wouldn't this prevent larger *Backtrace* buffers from getting shown
> below the selected window?

I see what you mean.  Then what about:

(window-min-height . ,(min 10 (with-current-buffer debugger-buffer (count-lines (point-min) (point-max)))))

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > I see what you mean.  Then what about:
 >
 > (window-min-height . ,(min 10 (with-current-buffer debugger-buffer (count-lines (point-min) (point-max)))))

This should never harm.  But can you please brush up my rudimentary
patch if needed.  It's installed here but my private settings don't
allow for testing more typical use-cases.

Thanks, martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> I see what you mean.  Then what about:
>>
>> (window-min-height . ,(min 10 (with-current-buffer debugger-buffer (count-lines (point-min) (point-max)))))
>
> This should never harm.  But can you please brush up my rudimentary
> patch if needed.  It's installed here but my private settings don't
> allow for testing more typical use-cases.

Please install it as is, I tried it and see no big problems.
Then later it could be amended with more improvements.

One problem not related to your patch is that when display-buffer-below-selected
fails, then the *Backtrace* buffer is still displayed in a random window,
not remembering its previous window.  A possible solution is
to prefer get-mru-window over get-lru-window as the default fallback.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > Please install it as is, I tried it and see no big problems.
 > Then later it could be amended with more improvements.

Installed.

 > One problem not related to your patch is that when display-buffer-below-selected
 > fails, then the *Backtrace* buffer is still displayed in a random window,
 > not remembering its previous window.  A possible solution is
 > to prefer get-mru-window over get-lru-window as the default fallback.

IIRC you tried with 'display-buffer-at-bottom' as second default
alternative already and were content with it.

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> Please install it as is, I tried it and see no big problems.
>> Then later it could be amended with more improvements.
>
> Installed.

Sorry, I just noticed that the code that you moved was executed
in the *Backtrace* buffer because it was after the pop-to-buffer
call.  Now code such as `(count-lines (point-min) (point-max))'
is executed in another buffer before the pop-to-buffer call.

>> One problem not related to your patch is that when display-buffer-below-selected
>> fails, then the *Backtrace* buffer is still displayed in a random window,
>> not remembering its previous window.  A possible solution is
>> to prefer get-mru-window over get-lru-window as the default fallback.
>
> IIRC you tried with 'display-buffer-at-bottom' as second default
> alternative already and were content with it.

Adding 'display-buffer-at-bottom' would be good.
Customizing get-mru-window over get-lru-window would
be good too, I remember you already sent a patch for that ;)

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > Sorry, I just noticed that the code that you moved was executed
 > in the *Backtrace* buffer because it was after the pop-to-buffer
 > call.  Now code such as `(count-lines (point-min) (point-max))'
 > is executed in another buffer before the pop-to-buffer call.

I tried to fix that now but have no idea about the purpose of

		  (message "%s" (buffer-string))
		  (kill-emacs -1)

and whether their new position (before the 'pop-to-buffer') may cause
any problems.  Please check.

 > Adding 'display-buffer-at-bottom' would be good.
 > Customizing get-mru-window over get-lru-window would
 > be good too, I remember you already sent a patch for that ;)

I don't remember that ;)

martin

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > Another problem with 'append' is that when the user switches
 > to the window where *Backtrace* was displayed last time,
 > and types 'C-x C-e' in that window, then *Backtrace* will be
 > displayed in the same window.  Maybe it should have
 > (inhibit-same-window . t)?

I wouldn't mind adding such a restriction.  Would you condition it on
the 'append' case or do it generally?

martin

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

>> Another problem with 'append' is that when the user switches
>> to the window where *Backtrace* was displayed last time,
>> and types 'C-x C-e' in that window, then *Backtrace* will be
>> displayed in the same window.  Maybe it should have
>> (inhibit-same-window . t)?
>
> I wouldn't mind adding such a restriction.  Would you condition it on
> the 'append' case or do it generally?

It seems this problem doesn't exist for other cases.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 >>> Another problem with 'append' is that when the user switches
 >>> to the window where *Backtrace* was displayed last time,
 >>> and types 'C-x C-e' in that window, then *Backtrace* will be
 >>> displayed in the same window.  Maybe it should have
 >>> (inhibit-same-window . t)?
 >>
 >> I wouldn't mind adding such a restriction.  Would you condition it on
 >> the 'append' case or do it generally?
 >
 > It seems this problem doesn't exist for other cases.

But could it harm to add an 'inhibit-same-window' for other cases?

Anyway, could you provide a patch?  To be honest, I don't grok the
idea of 'debugger-previous-window' in

	      (pop-to-buffer
	       debugger-buffer
	       `((display-buffer-reuse-window
		  display-buffer-in-previous-window)
		 . (,(when (and (window-live-p debugger-previous-window)
				(frame-visible-p
				 (window-frame debugger-previous-window)))
		       `(previous-window . ,debugger-previous-window)))))

any more and am afraid to do more damage than fix anything.

martin

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> To be honest, I don't grok the idea of 'debugger-previous-window' in
>
> 	      (pop-to-buffer
> 	       debugger-buffer
> 	       `((display-buffer-reuse-window
> 		  display-buffer-in-previous-window)
> 		 . (,(when (and (window-live-p debugger-previous-window)
> 				(frame-visible-p
> 				 (window-frame debugger-previous-window)))
> 		       `(previous-window . ,debugger-previous-window)))))
>
> any more and am afraid to do more damage than fix anything.

'debugger-previous-window' had been introduced because the debugger
buffer jumped around in a frame's windows every time the debugger was
reentered - e.g. when you stepped through code with d, d, ..., and there
were multiple windows in the selected frame, with every d hit, the
debugger would appear in a different window.

AFAIR the fix was rather simple: The var `debugger-previous-window'
is updated as long as the debugger will be reentered - when leaving the
debugger, it is reset to nil.

The code you cited just implements that the variable's value is
respected.

Our issue here is a different one: we want the debugger to use the
latest selected window for a _new_ debugger session.

I'm not sure if we could reuse 'debugger-previous-window' for fixing
this issue, but AFAIR it was important that the variable is reset to nil
after a debugger session is finished.  The answer can probably be found
in the message archives.


Michael.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > 'debugger-previous-window' had been introduced because the debugger
 > buffer jumped around in a frame's windows every time the debugger was
 > reentered - e.g. when you stepped through code with d, d, ..., and there
 > were multiple windows in the selected frame, with every d hit, the
 > debugger would appear in a different window.
 >
 > AFAIR the fix was rather simple: The var `debugger-previous-window'
 > is updated as long as the debugger will be reentered - when leaving the
 > debugger, it is reset to nil.
 >
 > The code you cited just implements that the variable's value is
 > respected.
 >
 > Our issue here is a different one: we want the debugger to use the
 > latest selected window for a _new_ debugger session.
 >
 > I'm not sure if we could reuse 'debugger-previous-window' for fixing
 > this issue, but AFAIR it was important that the variable is reset to nil
 > after a debugger session is finished.  The answer can probably be found
 > in the message archives.

Thanks for the explanation.  If we really have to reset
'debugger-previous-window' to nil (I can't imagine why this would be
necessary) we could still add yet another variable, say
'debugger-last-session-window' and use that in a new session if it's
still alive.  The problem, to recall, is that having *Backtrace* in
the list of previous buffer of a window can be a nuisance - one never
wants to switch to it via 'previous-buffer'.

Whatever we do there: Could you make the 'inhibit-same-window' change
Juri asked for?  I trust you more than myself in this regard.

Also I faintly recall that at least one of your bug reports wrt
debugging and windows was never closed.  Is that true?

martin

bug#32825: 27.0.50; Deterministic window management

[Noam Postavsky]

martin rudalics <rudalics@gmx.at> writes:

>> I'm not sure if we could reuse 'debugger-previous-window' for fixing
>> this issue, but AFAIR it was important that the variable is reset to nil
>> after a debugger session is finished.  The answer can probably be found
>> in the message archives.
>
> Thanks for the explanation.  If we really have to reset
> 'debugger-previous-window' to nil (I can't imagine why this would be
> necessary)

It was for Bug#17882.  I thought the simpler fix was just to reset the
variable after the debugger goes away, but the alternate suggestion
there of checking the visibility could probably work too.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > It was for Bug#17882.

Fine.  There I wrote

 > Check it in.  I doubt we'll get any complaints for this.

which clearly shows the quality of my judgements in this context.

 > I thought the simpler fix was just to reset the
 > variable after the debugger goes away, but the alternate suggestion
 > there of checking the visibility could probably work too.

Wouldn't we have to check that the window is not another frame in
order to avoid Bug#17882?

martin

bug#32825: 27.0.50; Deterministic window management

[Noam Postavsky]

martin rudalics <rudalics@gmx.at> writes:

>> I thought the simpler fix was just to reset the
>> variable after the debugger goes away, but the alternate suggestion
>> there of checking the visibility could probably work too.
>
> Wouldn't we have to check that the window is not another frame in
> order to avoid Bug#17882?

Oh, yes, I suppose so.  A check soley for visibility would only address
the "especially annoying when I happen to work in another frame, on
another desktop" scenario.  I don't usually have mutiple frames visible
so I didn't think of it.

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

Noam Postavsky <npostavs@gmail.com> writes:

> Oh, yes, I suppose so.  A check soley for visibility would only
> address the "especially annoying when I happen to work in another
> frame, on another desktop" scenario.  I don't usually have mutiple
> frames visible so I didn't think of it.

Ehm - Noam, since you seem the most knowing of us all, could you maybe
please care about this report?


Michael.

bug#32825: 27.0.50; Deterministic window management

[Noam Postavsky]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Noam Postavsky <npostavs@gmail.com> writes:
>
>> Oh, yes, I suppose so.  A check soley for visibility would only
>> address the "especially annoying when I happen to work in another
>> frame, on another desktop" scenario.  I don't usually have mutiple
>> frames visible so I didn't think of it.
>
> Ehm - Noam, since you seem the most knowing of us all, could you maybe
> please care about this report?

I just happened to remember about the debugger-previous-window thing
with Bug#17882, I don't know what's the right solution to this bug.

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

Noam Postavsky <npostavs@gmail.com> writes:

> I just happened to remember about the debugger-previous-window thing
> with Bug#17882, I don't know what's the right solution to this bug.

Thanks.  So far, I also just remember it because I had been involved in
reporting that bug.

I can have an eye on whether a fix makes sense to me, but I don't know
enough about the matter to decide how a good fix must look like.


Michael.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

 > Ehm - Noam, since you seem the most knowing of us all, could you maybe
 > please care about this report?

So we got a hot potato here.  Let me try to recapitulate what should
be done:

(1) Try to never display the *Backtrace* buffer in the selected (aka
same) window.  So far, we all agreed on that and nobody asked for an
exception from this rule.

(2) Try to keep 'debugger-previous-window' around even after the
debugger session has been closed.  Doing that naively will get us back
Bug#17882.  So we probably don't want to use
'debugger-previous-window' in a new session when it is on another
frame (or display).  But we could use it even in a new session when it
is on the selected frame and not the selected window.

This should take care of the default value of 'debugger-bury-or-kill'
- the immediate problem that caused this bug report.  Does anyone see
a problem with this?

I attach a preliminary patch.  Please try it and tell me whether you
see any difficulties with it.

Thanks, martin

[-- Attachment #2: debug.diff --]
[-- Type: text/plain, Size: 2177 bytes --]

--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -101,7 +101,10 @@ debugger-old-buffer
   "This is the buffer that was current when the debugger was entered.")
 
 (defvar debugger-previous-window nil
-  "This is the window last showing the debugger buffer.")
+  "The last debugger window from the same session.")
+
+(defvar debugger-pre-previous-window nil
+  "The last debugger window from the previous session.")
 
 (defvar debugger-previous-window-height nil
   "The last recorded height of `debugger-previous-window'.")
@@ -240,10 +243,16 @@ debug
 	       debugger-buffer
 	       `((display-buffer-reuse-window
 		  display-buffer-in-previous-window)
-		 . (,(when (and (window-live-p debugger-previous-window)
-				(frame-visible-p
-				 (window-frame debugger-previous-window)))
-		       `(previous-window . ,debugger-previous-window)))))
+		 . (,(cond
+                      ((and (window-live-p debugger-previous-window)
+			    (frame-visible-p
+			     (window-frame debugger-previous-window)))
+		       `(previous-window . ,debugger-previous-window))
+                      ((and (window-live-p debugger-pre-previous-window)
+                            (eq (window-frame debugger-pre-previous-window)
+                                (selected-frame)))
+		       `(previous-window . ,debugger-pre-previous-window)))
+                    (inhibit-same-window . t))))
 	      (setq debugger-window (selected-window))
 	      (if (eq debugger-previous-window debugger-window)
 		  (when debugger-jumping-flag
@@ -297,7 +306,9 @@ debug
 		(quit-restore-window debugger-window debugger-bury-or-kill)
 		;; Restore current buffer (Bug#12502).
 		(set-buffer debugger-old-buffer)))
-            ;; Forget debugger window, it won't be back (Bug#17882).
+            ;; Forget debugger window, it won't be back (Bug#17882)
+            ;; unless it's on the selected frame (Bug#32825).
+            (setq debugger-pre-previous-window debugger-previous-window)
             (setq debugger-previous-window nil))
           ;; Restore previous state of debugger-buffer in case we were
           ;; in a recursive invocation of the debugger, otherwise just

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> I attach a preliminary patch.  Please try it and tell me whether you
> see any difficulties with it.

Haven't tried it yet, but makes sense to me.

What I don't like so much is that, in effect, we use
`display-buffer-in-previous-window', whose behavior is user
configurable, but we don't like some if its semantics, so we overwrite
them by specifying the previous-window property dynamically generated.
This does what we want, but it is not user configurable any more.  If,
for example, a user wants to always use a special frame for the
debugger, he can't get that.

Would it be worth it to factor out the pop-to-buffer action as a
(function valued) user option?


Michael.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > What I don't like so much is that, in effect, we use
 > `display-buffer-in-previous-window', whose behavior is user
 > configurable, but we don't like some if its semantics, so we overwrite
 > them by specifying the previous-window property dynamically generated.
 > This does what we want, but it is not user configurable any more.  If,
 > for example, a user wants to always use a special frame for the
 > debugger, he can't get that.

Why not?  Users can always provide their customizations via
'display-buffer-alist'.  Using, for example

(push '("*Backtrace*" (display-buffer-reuse-window display-buffer-pop-up-frame) (reusable-frames . t))
       display-buffer-alist)

The argument provided by 'debug' is for users who don't intend to
customize the behavior.

martin

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> > What I don't like so much is that, in effect, we use
> > `display-buffer-in-previous-window', whose behavior is user
> > configurable, but we don't like some if its semantics, so we overwrite
> > them by specifying the previous-window property dynamically generated.
> > This does what we want, but it is not user configurable any more.  If,
> > for example, a user wants to always use a special frame for the
> > debugger, he can't get that.
>
> Why not?  Users can always provide their customizations via
> 'display-buffer-alist'.  Using, for example
>
> (push '("*Backtrace*" (display-buffer-reuse-window
> display-buffer-pop-up-frame) (reusable-frames . t))
>       display-buffer-alist)

What I meant was "always use a special, but always one and the same
frame".  The 'reusable-frame' association in your 'display-buffer-alist'
entry doesn't accomplish that, because when pop-to-buffer is called, the
*Backtrace* buffer is typically not shown anymore at that moment in that
frame.


Michael.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 >> (push '("*Backtrace*" (display-buffer-reuse-window
 >> display-buffer-pop-up-frame) (reusable-frames . t))
 >>        display-buffer-alist)
 >
 > What I meant was "always use a special, but always one and the same
 > frame".

Users have all possible freedom in this regard.  Your "always use a
special, but always one and the same frame" would have to be specified
more precisely but there is no reason it cannot be done.  For example,
users who want to use a dedicated frame for that purpose can write
their own 'my-display-backtrace' function which creates that frame if
necessary, remembers it in a variable of their choice, and reuses it -
from that variable - in a later invocation.

 > The 'reusable-frame' association in your 'display-buffer-alist'
 > entry doesn't accomplish that, because when pop-to-buffer is called, the
 > *Backtrace* buffer is typically not shown anymore at that moment in that
 > frame.

Users who want to leave the initial choice of the window to 'debug'
and only chime in later can use 'debugger-previous-window' and
'debugger-pre-previous-window' in their customizations.

I'm afraid that yours is yet another example of how difficult it is to
customize 'display-buffer-alist'.  Back then, I warned Stefan and
Chong that this would happen.  But they argumented with the greater
flexibility of the action functions/action alist approach.  So once
more: 'display-buffer-alist' allows you to do virtually everything and
thus override and reuse anything 'debug' does.  But it might not be
intuitive to do that and sometimes requires to read the code of the
invoker of 'display-buffer' ('debug' in this case) in order to play
along with that.

martin

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> Users have all possible freedom in this regard.  Your "always use a
> special, but always one and the same frame" would have to be specified
> more precisely but there is no reason it cannot be done.  For example,
> users who want to use a dedicated frame for that purpose can write
> their own 'my-display-backtrace' function which creates that frame if
> necessary, remembers it in a variable of their choice, and reuses it -
> from that variable - in a later invocation.

Well, right.  It wasn't clear to me that `display-buffer-alist' takes
precedence over the ACTION arg of `pop-to-buffer'.  You can just define
your own action function.

> I'm afraid that yours is yet another example of how difficult it is to
> customize 'display-buffer-alist'.

I fine with it.  There are lots of different possible semantics, so it's
natural that some of them make defining a new function necessary.

The special thing in this example is that the action has to have a state
(remember the last window), so you have to use a closure.  Or you can
just use the value of `debugger-pre-previous-window'.  Seems acceptable
to me.


Michael.

bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> Also I faintly recall that at least one of your bug reports wrt
> debugging and windows was never closed.  Is that true?

Which one was that - I don't remember.


Michael.

bug#32825: 27.0.50; Deterministic window management

[Noam Postavsky]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> martin rudalics <rudalics@gmx.at> writes:
>
>> Also I faintly recall that at least one of your bug reports wrt
>> debugging and windows was never closed.  Is that true?
>
> Which one was that - I don't remember.

All unarchived reports from your current email address are list here:
https://debbugs.gnu.org/cgi/pkgreport.cgi?submitter=michael_heerdegen%40web.de

Bug#12921 could fit.

bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

 > Bug#12921 could fit.

Indeed, that's the one I meant.

Thanks for the bug memory, martin

bug#32825: 27.0.50; Deterministic window management

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> 0. emacs -Q
>
> 1. create 3 windows, e.g.:
>    C-x 3
>    C-x 2
>
> 2. type a random letter, e.g. 'z'
>
> 3. eval it with 'C-x C-e'
>    the *Backtrace* buffer with an error appears in some window,
>    quit it with 'q'
>
> 4. eval again exactly with the same key 'C-x C-e',
>    the *Backtrace* buffer appears in another window,
>    not where it appeared the previous time.
>
> What is expected: window management should be more deterministic in the
> sense that the result of the window operation should be expected beforehand,
> not popping windows in random places.

This was a really long bug thread, and only skimmed extremely lightly.

This test case behaves as it should in Emacs 29 -- i.e., the *Backtrace*
window appears in the same place every time.

Are there any other things in this bug report that should be done?  If
so, perhaps it'd make sense to open a new bug report to summarise what
should be done?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32825: 27.0.50; Deterministic window management

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> This was a really long bug thread, and only skimmed extremely lightly.
                                         ^I

(Fun fact -- it's the longest open bug thread at 134 messages and
counting.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32825: 27.0.50; Deterministic window management

[Juri Linkov]

close 32825 29.0.50
thanks

>> This was a really long bug thread, and only skimmed extremely lightly.
>                                          ^I
>
> (Fun fact -- it's the longest open bug thread at 134 messages and
> counting.)

Then let's apply for a Guinness World Record with this thread,
and start a new in bug#55169.