bug#7368: 23.2; Python interpreter buffer should never appear in separate frame

bug#7368: 23.2; Python interpreter buffer should never appear in separate frame

[Andrey Paramonov]

Hello!

Most of the time, python-switch-to-python splits current frame and
activates Python interpreter buffer in a new window. This is handy and
consistent with other interpreter modes, i.e. ESS.

However, *sometimes* Python interpreter is activated in a separate
frame. This is very inconvenient, especially because of
"sometimes". Python interpreter buffer should always appear in the
current frame, and never in separate frame.

To reproduce:

0) emacs -Q

1) Create/open the following minimal example (| shows cursor pos):

import os.path

os.path.|

2) Press C-c C-z. Python interpreter buffer appears *in a new
window*. This is correct.

3) Switch to python code buffer, press ESC-ESC-ESC.

4) Press M-Tab. Completion buffer appears in a new window. This is
correct.

5) Press C-c C-z. Python interpreter buffer pops up *in a new
frame*. This is incorrect.

I'm ready to provide any additional info,
Andrey Paramonov

In GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0)
 of 2010-08-15 on raven, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
configured using `configure  '--build' 'i486-linux-gnu' '--build' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.2/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.2/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ru_RU.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Inferior Python

Minor modes in effect:
  compilation-shell-minor-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Fontifying *Python*... (regexps...........)
Making completion list... [2 times]

Load-path shadows:
/usr/share/emacs/23.2/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs/23.2/site-lisp/flim/md4 hides /usr/share/emacs/23.2/lisp/md4
/usr/share/emacs/23.2/site-lisp/flim/hex-util hides /usr/share/emacs/23.2/lisp/hex-util
/usr/share/emacs/23.2/site-lisp/flim/sha1 hides /usr/share/emacs/23.2/lisp/sha1
/usr/share/emacs/23.2/site-lisp/dictionaries-common/flyspell hides /usr/share/emacs/23.2/lisp/textmodes/flyspell
/usr/share/emacs/23.2/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/23.2/lisp/textmodes/ispell
/usr/share/emacs/23.2/site-lisp/flim/ntlm hides /usr/share/emacs/23.2/lisp/net/ntlm
/usr/share/emacs/23.2/site-lisp/flim/sasl-cram hides /usr/share/emacs/23.2/lisp/net/sasl-cram
/usr/share/emacs/23.2/site-lisp/flim/sasl hides /usr/share/emacs/23.2/lisp/net/sasl
/usr/share/emacs/23.2/site-lisp/flim/sasl-ntlm hides /usr/share/emacs/23.2/lisp/net/sasl-ntlm
/usr/share/emacs/23.2/site-lisp/flim/sasl-digest hides /usr/share/emacs/23.2/lisp/net/sasl-digest
/usr/share/emacs/23.2/site-lisp/flim/hmac-md5 hides /usr/share/emacs/23.2/lisp/net/hmac-md5
/usr/share/emacs/23.2/site-lisp/flim/hmac-def hides /usr/share/emacs/23.2/lisp/net/hmac-def

Features:
(shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml
mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util
netrc time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock
sha1 sha1-el hex-util hashcash mail-utils emacsbug compile python-21
python comint ring help-mode easymenu view cyril-util tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd
fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer
select scroll-bar mldrag mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces
cus-face files text-properties overlay md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote
make-network-process dbusbind system-font-setting font-render-setting
gtk x-toolkit x multi-tty emacs)

bug#7368: Testcase

[Андрей Парамонов]

It turns out that the problem is not specific to Python mode. The
following minimal example reproduces it.

C-h v pop-up-frames RET says:

pop-up-frames's value is nil

Documentation:
Whether `display-buffer' should make a separate frame.
If nil, never make a separate frame.

However, a new frame *does* pop up for me after running the following code:

(let ((foo (get-buffer-create "foo.el"))
      (bar (get-buffer-create "bar.el")))
  (switch-to-buffer foo)
  (delete-other-windows)
  (completion-at-point)
  (display-buffer bar t))

Best wishes,
Andrey Paramonov

bug#7368: Testcase

[martin rudalics]

 > C-h v pop-up-frames RET says:
 >
 > pop-up-frames's value is nil
 >
 > Documentation:
 > Whether `display-buffer' should make a separate frame.
 > If nil, never make a separate frame.
 >
 > However, a new frame *does* pop up for me after running the following code:
 >
 > (let ((foo (get-buffer-create "foo.el"))
 >       (bar (get-buffer-create "bar.el")))
 >   (switch-to-buffer foo)
 >   (delete-other-windows)
 >   (completion-at-point)
 >   (display-buffer bar t))

On my trunk Emacs your code produces a new window on the selected frame.
Apparently, some of your settings prevent it from splitting the selected
window and the second argument t means `display-buffer' must not reuse
the selected window.  So `display-buffer' simply has no other choice but
making a new frame.

BTW, the snippet

(progn
   (delete-other-windows)
   (display-buffer (other-buffer) t))

should be sufficient for exhibiting the behavior you observe.

martin

bug#7368: Testcase

[Андрей Парамонов]

2010/11/13 martin rudalics <rudalics@gmx.at>:
> On my trunk Emacs your code produces a new window on the selected frame.

Ah, sorry. Here is the modified version which I've actually checked ;-)

(let ((foo (get-buffer-create "foo.el"))
      (bar (get-buffer-create "bar.el")))
  (switch-to-buffer foo)
  (delete-other-windows)
  (emacs-lisp-mode)
  (insert "(a")
  (completion-at-point)
  (display-buffer bar t))

> So `display-buffer' simply has no other choice but
> making a new frame.

In principle, in this very awkward situation display-buffer has 3 options:

1) To display buffer in selected window -- but not-in-this-window=t.

2) To display buffer in a new frame -- but pop-up-frames says we
*never* make a separate frame.

3) To display buffer in place of completions window -- but that window
is "dedicated".

To me option 3 seems the least unexpected.

Anyway, something needs to be fixed, as current documentation for
pop-up-frames is wrong.

> BTW, the snippet
>
> (progn
>  (delete-other-windows)
>  (display-buffer (other-buffer) t))
>
> should be sufficient for exhibiting the behavior you observe.

No, the completions buffer plays important role.

Thanks for your support,
Andrey Paramonov

bug#7368: Testcase

[martin rudalics]

 > In principle, in this very awkward situation display-buffer has 3 options:
 >
 > 1) To display buffer in selected window -- but not-in-this-window=t.
 >
 > 2) To display buffer in a new frame -- but pop-up-frames says we
 > *never* make a separate frame.
 >
 > 3) To display buffer in place of completions window -- but that window
 > is "dedicated".
 >
 > To me option 3 seems the least unexpected.

Anything can happen here.  If `display-buffer' doesn't find a better
window "the normal way", it may use the selected or the dedicated window
as well.

 > Anyway, something needs to be fixed, as current documentation for
 > pop-up-frames is wrong.

Most `display-buffer' related doc-strings are "wrong" in this regard.
They are based on behaviors where at least one approach gets through
"the normal way".  Note that `display-buffer' is supposed to _always_
return a window although you can easily set up options in a way that do
not allow to do that (as in your example).

We would have to introduce some sort of priority telling Emacs which
option is allowed to violate which restriction in which order, document
that, and confuse people even more.

BTW, you might want to have a look at my window-pub branch where all
`display-buffer' related options are combined in two almost identic
options called `display-buffer-names' and `display-buffer-regexps'.  The
doc-string of the former and its documentation are formulated in less
stringent terms.

 >> BTW, the snippet
 >>
 >> (progn
 >>  (delete-other-windows)
 >>  (display-buffer (other-buffer) t))
 >>
 >> should be sufficient for exhibiting the behavior you observe.
 >
 > No, the completions buffer plays important role.

Make your frame small enough and you can see the problem here too.

martin

bug#7368: Testcase

[Stefan Monnier]

> In principle, in this very awkward situation display-buffer has 3 options:

> 1) To display buffer in selected window -- but not-in-this-window=t.

> 2) To display buffer in a new frame -- but pop-up-frames says we
> *never* make a separate frame.

> 3) To display buffer in place of completions window -- but that window
> is "dedicated".

It's actually soft-dedicated (i.e. dedicated but switch-to-buffer can
override it).

> To me option 3 seems the least unexpected.

Agreed.  Another option is to create a third window.


        Stefan

bug#7368: Testcase

[Андрей Парамонов]

2010/11/16 Stefan Monnier <monnier@iro.umontreal.ca>:
> It's actually soft-dedicated (i.e. dedicated but switch-to-buffer can
> override it).

After another debug session I see that there are 2 types of special windows:

1) A "softly dedicated" window is a window with 2 properties:
  a) it is tied to a certain buffer, and when that buffer is destroyed
the window is destroyed too;
  b) it cannot be target of display-buffer.

2) A "truly dedicated" window is a window with 3 properties:
  a) it is tied to a certain buffer, and when that buffer is destroyed
the window is destroyed too;
  b) it cannot be target of display-buffer;
  c) it cannot be target of switch-to-buffer.

Wouldn't it be more logical to have the following?

1) A "softly dedicated" window is a window tied to a certain buffer,
and when that buffer is destroyed the window is destroyed too.

2) A "truly dedicated" window is a "softly dedicated" window which
cannot be target of neither display-buffer nor switch-to-buffer.

That would solve the problem, but I'm beginning to doubt if it's worth
it to solve the problem generally...

Best wishes,
Andrey Paramonov

bug#7368: Testcase

[Stefan Monnier]

> After another debug session I see that there are 2 types of special windows:

> 1) A "softly dedicated" window is a window with 2 properties:
>   a) it is tied to a certain buffer, and when that buffer is destroyed
> the window is destroyed too;
>   b) it cannot be target of display-buffer.

> 2) A "truly dedicated" window is a window with 3 properties:
>   a) it is tied to a certain buffer, and when that buffer is destroyed
> the window is destroyed too;
>   b) it cannot be target of display-buffer;
>   c) it cannot be target of switch-to-buffer.

> Wouldn't it be more logical to have the following?

> 1) A "softly dedicated" window is a window tied to a certain buffer,
> and when that buffer is destroyed the window is destroyed too.

I think in general that would not be right (e.g. for my use of
soft-dedicated windows).  But I agree that display-buffer should
probably override the soft-dedication in the case where it would
otherwise have to create a new frame and the user has pop-up-frames set
to nil.


        Stefan

bug#7368: display-buffer a softly dedicated window

[Андрей Парамонов]

2010/11/17 Stefan Monnier <monnier@iro.umontreal.ca>:
>> 1) A "softly dedicated" window is a window tied to a certain buffer,
>> and when that buffer is destroyed the window is destroyed too.
>
> I think in general that would not be right (e.g. for my use of
> soft-dedicated windows).

I'm curious what is your use-case. Would truly-dedicated windows fit it?

> But I agree that display-buffer should
> probably override the soft-dedication in the case where it would
> otherwise have to create a new frame and the user has pop-up-frames set
> to nil.
>

I bevieve it's reasonable to override soft-dedication unconditionally.
The checks for dedicated != nil seem to be needed only because
switch-to-buffer would fail on a "truly dedicated" buffer. However,
switch-to-buffer would never fail on a "softly dedicated" buffer, only
on a "truly dedicated" one, so it seems logical to rather check for
dedicated = t.

I strongly believe display-buffer and switch-to-buffer should do the
same thing in the following minimal example:

(let ((foo (get-buffer-create "foo"))
     (bar (get-buffer-create "bar"))
     (baz (get-buffer-create "baz")))
 (switch-to-buffer foo)
 (delete-other-windows)
 (let ((bar-window (display-buffer bar t)))
   (set-window-dedicated-p bar-window 'soft)
   (select-window bar-window)
   (switch-to-buffer baz)))

(let ((foo (get-buffer-create "foo"))
     (bar (get-buffer-create "bar"))
     (baz (get-buffer-create "baz")))
 (switch-to-buffer foo)
 (delete-other-windows)
 (let ((bar-window (display-buffer bar t)))
   (set-window-dedicated-p bar-window 'soft))
 (display-buffer baz t))

For that to work, only a small patch for get-lru-window and
get-largest-window is needed. However I understand that although
logical, this tiny change might break something. Should I relabel the
bug accordingly, or create a new one?

Best wishes,
Andrey Paramonov

bug#7368: Testcase

[martin rudalics]

 > 1) A "softly dedicated" window is a window with 2 properties:
 >   a) it is tied to a certain buffer, and when that buffer is destroyed
 > the window is destroyed too;

Not necessarily.  If there are no other windows left or the window
previoulsy showed another buffer the window is not destroyed.

 >   b) it cannot be target of display-buffer.
 >
 > 2) A "truly dedicated" window is a window with 3 properties:
 >   a) it is tied to a certain buffer, and when that buffer is destroyed
 > the window is destroyed too;

See above.

 >   b) it cannot be target of display-buffer;
 >   c) it cannot be target of switch-to-buffer.

It cannot be target of `set-window-buffer' which subsumes all other cases.

martin

bug#7368: display-buffer a softly dedicated window

[martin rudalics]

 > I bevieve it's reasonable to override soft-dedication unconditionally.
 > The checks for dedicated != nil seem to be needed only because
 > switch-to-buffer would fail on a "truly dedicated" buffer. However,
 > switch-to-buffer would never fail on a "softly dedicated" buffer,

It could fail because it falls back on `display-buffer' when the
selected window is a minibuffer window or dedicated.  `pop-to-buffer'
and the remaining members of the `switch-to-buffer' family always fail
to use a weakly dedicated window.

martin

bug#7368: display-buffer a softly dedicated window

[Андрей Парамонов]

2010/11/17 martin rudalics <rudalics@gmx.at>:
>> I bevieve it's reasonable to override soft-dedication unconditionally.
>> The checks for dedicated != nil seem to be needed only because
>> switch-to-buffer would fail on a "truly dedicated" buffer. However,
>> switch-to-buffer would never fail on a "softly dedicated" buffer,
>
> It could fail because it falls back on `display-buffer' when the
> selected window is a minibuffer window or dedicated.  `pop-to-buffer'
> and the remaining members of the `switch-to-buffer' family always fail
> to use a weakly dedicated window.
>

I mean override soft-dedication *inside* display-buffer. And
switch-to-buffer actually doesn't fail to override "softly dedicated"
window (see my examle).

Andrey Paramonov

bug#7368: display-buffer a softly dedicated window

[Stefan Monnier]

> I strongly believe display-buffer and switch-to-buffer should do the
> same thing in the following minimal example:

This is irrelevant because calling switch-to-buffer from Elisp is a bug
in my book.

One important property of soft-dedicated windows is that the window's buffer
won't be changed except upon explicit request from the user (with C-x b).


        Stefan

bug#7368: display-buffer a softly dedicated window

[martin rudalics]

 >> It could fail because it falls back on `display-buffer' when the
 >> selected window is a minibuffer window or dedicated.  `pop-to-buffer'
 >> and the remaining members of the `switch-to-buffer' family always fail
 >> to use a weakly dedicated window.
 >>
 >
 > I mean override soft-dedication *inside* display-buffer. And
 > switch-to-buffer actually doesn't fail to override "softly dedicated"
 > window (see my examle).

It doesn't fail in your example.  I explained above how it can fail.

But rather than thinking about how to "fix" this I'd try to find out why
`display-buffer' is called _before_ burying the completions buffer.  The
plain fact that the completions buffer can be reused by `display-buffer'
indicates that it is no more useful at the time `display-buffer' gets
called.

martin

bug#7368: display-buffer a softly dedicated window

[Андрей Парамонов]

2010/11/17 martin rudalics <rudalics@gmx.at>:
> It doesn't fail in your example.  I explained above how it can fail.

Yes, I agree that switch-to-buffer fails, for example, if there is a
single window on a single frame :-)  I wanted to say the following:

1) In principle, switch-to-buffer may fail.

2) switch-to-buffer doesn't fail in

(let ((foo (get-buffer-create "foo"))
    (bar (get-buffer-create "bar"))
    (baz (get-buffer-create "baz")))
 (switch-to-buffer foo)
 (delete-other-windows)
 (let ((bar-window (display-buffer bar t)))
  (set-window-dedicated-p bar-window 'soft)
  (select-window bar-window)
  (switch-to-buffer baz)))

3) display-buffer uses switch-to-buffer as a subroutine.

4) display-buffer checks some conditions before calling
switch-to-buffer, because the latter may fail.

5) display-buffer fails in

(let ((foo (get-buffer-create "foo"))
    (bar (get-buffer-create "bar"))
    (baz (get-buffer-create "baz")))
 (switch-to-buffer foo)
 (delete-other-windows)
 (let ((bar-window (display-buffer bar t)))
  (set-window-dedicated-p bar-window 'soft))
 (display-buffer baz t))

6) This is because checks in display-buffer before calling
switch-to-buffer and inside switch-to-buffer are different.

7) I believe this is not logical and should be fixed.

8) I think there is an easy way to fix it by checking for dedicated =
t instead of dedicated != nil inside get-lru-window and
get-largest-window.

Do you agree with points 1-6?

> But rather than thinking about how to "fix" this I'd try to find out why
> `display-buffer' is called _before_ burying the completions buffer.  The
> plain fact that the completions buffer can be reused by `display-buffer'
> indicates that it is no more useful at the time `display-buffer' gets
> called.

You are right, completions buffer is not useful at the time
display-buffer is executed. Now completions buffer doesn't get buried
because no one buries it.

To bury it before display-buffer is my plan B actually ;-)  The
problem with this solution is that it's not general: one will have to
modify many top-level commands capable of displaying a buffer to bury
*Completions* beforehand.

Also such modification would most likely be rejected for upstream, as
properly coding when to bury *Completions* is not trivial, and that
nontrivial code would be in many places.

comint.el solves this problem somehow, but so far I'm not able to
fully understand the code. What I see is that comint.el 's
*Completions* intercepts keyboard events while it's active.

Andrey Paramonov

bug#7368: display-buffer a softly dedicated window

[martin rudalics]

 > 1) In principle, switch-to-buffer may fail.
 >
 > 2) switch-to-buffer doesn't fail in
 >
 > (let ((foo (get-buffer-create "foo"))
 >     (bar (get-buffer-create "bar"))
 >     (baz (get-buffer-create "baz")))
 >  (switch-to-buffer foo)
 >  (delete-other-windows)
 >  (let ((bar-window (display-buffer bar t)))
 >   (set-window-dedicated-p bar-window 'soft)
 >   (select-window bar-window)
 >   (switch-to-buffer baz)))
 >
 > 3) display-buffer uses switch-to-buffer as a subroutine.

That would be a very bad idea ;-)

 > 4) display-buffer checks some conditions before calling
 > switch-to-buffer, because the latter may fail.

As a matter of fact, both may fail.

 > 5) display-buffer fails in
 >
 > (let ((foo (get-buffer-create "foo"))
 >     (bar (get-buffer-create "bar"))
 >     (baz (get-buffer-create "baz")))
 >  (switch-to-buffer foo)
 >  (delete-other-windows)
 >  (let ((bar-window (display-buffer bar t)))
 >   (set-window-dedicated-p bar-window 'soft))
 >  (display-buffer baz t))
 >
 > 6) This is because checks in display-buffer before calling
 > switch-to-buffer and inside switch-to-buffer are different.

See above.

 > 7) I believe this is not logical and should be fixed.

If the window is dedicated for the sole purpose to make it disappear
when it's no more need I tend to agree.  There are better solutions.
But if an application is allowed to display another buffer _while the
completions window is shown_ it would be a bad idea to use the
completions window.

 > 8) I think there is an easy way to fix it by checking for dedicated =
 > t instead of dedicated != nil inside get-lru-window and
 > get-largest-window.

The _only_ purpose of weakly dedicated windows is to not allow
`display-buffer' to use them.  What else would they be good for after
your "fix"?  And what would you do if someone made completion windows
strongly dedicated to their buffer?

 > Do you agree with points 1-6?

If you rewrote them correctly, maybe.

 > You are right, completions buffer is not useful at the time
 > display-buffer is executed. Now completions buffer doesn't get buried
 > because no one buries it.

IIUC the sequence of events is

(1) the application issues a call for getting the name of a buffer,

(2) the user enters the name with the assistance of the completion
     routines,

(3) the completion routines return the name,

(4) the caller displays the buffer with that name.

Now why does the completion window not go away after (3) and before (4)
and what makes it go away after (4)?

 > To bury it before display-buffer is my plan B actually ;-)  The
 > problem with this solution is that it's not general: one will have to
 > modify many top-level commands capable of displaying a buffer to bury
 > *Completions* beforehand.

After returning a value the completions buffer should be buried
immediately.  So there must be something tricky in this.

 > Also such modification would most likely be rejected for upstream, as
 > properly coding when to bury *Completions* is not trivial, and that
 > nontrivial code would be in many places.

It's not the task of the application to care about the window.

 > comint.el solves this problem somehow, but so far I'm not able to
 > fully understand the code. What I see is that comint.el 's
 > *Completions* intercepts keyboard events while it's active.

That's not very nice either :-(

martin

bug#7368: display-buffer a softly dedicated window

[Андрей Парамонов]

2010/11/17 martin rudalics <rudalics@gmx.at>:
>> Do you agree with points 1-6?
>
> If you rewrote them correctly, maybe.

Ok, let's try again ;-)  I completely messed up set-window-buffer and
switch-to-buffer, sorry.

1) In principle, set-window-buffer may fail.

2) set-window-buffer doesn't fail in

(let ((foo (get-buffer-create "foo"))
      (bar (get-buffer-create "bar"))
      (baz (get-buffer-create "baz")))
  (switch-to-buffer foo)
  (delete-other-windows)
  (let ((bar-window (display-buffer bar t)))
    (set-window-dedicated-p bar-window 'soft)
    (set-window-buffer bar-window baz)))

3) display-buffer uses set-window-buffer as a subroutine.

4) display-buffer checks some conditions before calling
set-window-buffer, because the latter may fail.

5) display-buffer fails in

(let ((foo (get-buffer-create "foo"))
      (bar (get-buffer-create "bar"))
      (baz (get-buffer-create "baz")))
  (switch-to-buffer foo)
  (delete-other-windows)
  (let ((bar-window (display-buffer bar t)))
    (set-window-dedicated-p bar-window 'soft))
  (display-buffer baz t))

6) This is because checks in display-buffer before calling
set-window-buffer and inside set-window-buffer are different.

7) I believe this is not logical and should be fixed.

8) I think there is an easy way to fix it by checking for dedicated =
t instead of dedicated != nil inside get-lru-window and
get-largest-window (by the way, is there any chance those are
implemented in Lisp?).

2010/11/17 martin rudalics <rudalics@gmx.at>:
> If the window is dedicated for the sole purpose to make it disappear
> when it's no more need I tend to agree.  There are better solutions.

Please tell which.

> But if an application is allowed to display another buffer _while the
> completions window is shown_ it would be a bad idea to use the
> completions window.

The minibuffer.el 's completion mechanism does not impose any
restrictions on what you can do while *Completions* is visible. That's
slightly off-topic, but I think it allows more user freedom and
clearer code.

> The _only_ purpose of weakly dedicated windows is to not allow
> `display-buffer' to use them.

I disagree. As a matter of fact, weakly dedicated windows possess
another property: they are deleted when their buffer is killed.

As a matter of personal opinion, "not allow `display-buffer' to use
them, but allow `set-window-buffer' to use them" is very hard concept
to understand. Especially given that `display-buffer' uses
`set-window-buffer' inside ;-) Even harder to understand is the
distinction between weakly and truly dedication.

I think that the following is much easier to grasp (although that's
not the primary goal):

1) Weakly dedicated: auto-closes when it's buffer is closed.

2) Truly dedicated: cannot display another buffer, auto-closes when
it's buffer is closed.

> What else would they be good for after
> your "fix"?  And what would you do if someone made completion windows
> strongly dedicated to their buffer?

I do not know. But thinking a bit, completion windows would be
"persistent" (would not disappear until you kill it explicitly). I can
imagine it might be not useless.

However I personally wouldn't make them strongly dedicated and
wouldn't advice to do so.

> IIUC the sequence of events is
>
> (1) the application issues a call for getting the name of a buffer,
>
> (2) the user enters the name with the assistance of the completion
>    routines,
>
> (3) the completion routines return the name,
>
> (4) the caller displays the buffer with that name.
>

No. The command showing *Completions* and command calling
display-buffer are totally unrelated. See the first message.

Best wishes,
Andrey Paramonov

bug#7368: display-buffer a softly dedicated window

[martin rudalics]

 > 1) In principle, set-window-buffer may fail.

When the window is strongly dedicated to its buffer and doesn't show the
buffer already.

 > 2) set-window-buffer doesn't fail in
 >
 > (let ((foo (get-buffer-create "foo"))
 >       (bar (get-buffer-create "bar"))
 >       (baz (get-buffer-create "baz")))
 >   (switch-to-buffer foo)
 >   (delete-other-windows)
 >   (let ((bar-window (display-buffer bar t)))
 >     (set-window-dedicated-p bar-window 'soft)
 >     (set-window-buffer bar-window baz)))
 >
 > 3) display-buffer uses set-window-buffer as a subroutine.
 >
 > 4) display-buffer checks some conditions before calling
 > set-window-buffer, because the latter may fail.

To avoid that `set-window-buffer' reports an error.

 > 5) display-buffer fails in
 >
 > (let ((foo (get-buffer-create "foo"))
 >       (bar (get-buffer-create "bar"))
 >       (baz (get-buffer-create "baz")))
 >   (switch-to-buffer foo)
 >   (delete-other-windows)
 >   (let ((bar-window (display-buffer bar t)))
 >     (set-window-dedicated-p bar-window 'soft))
 >   (display-buffer baz t))
 >

The fact that it doesn't use bar-window for displaying the buffer is not
a "failure" per se.

 > 6) This is because checks in display-buffer before calling
 > set-window-buffer and inside set-window-buffer are different.

Yes.

 > 7) I believe this is not logical and should be fixed.

Logic is in the mind of the beholder.  I can see two reasons for making
a window weakly dedicated:

(a) Give the application programmer a way to tell `display-buffer' that
     it should finding another window for displaying the buffer.  The
     user is allowed to switch to another buffer whenever she wants to.

(b) Make the window disappear when it's no more needed.

If there's consensus that (a) is not needed or useful I agree with your
conclusion.  Personally, I do not need weakly dedicated windows, so I
have no opinion about this.

 > 8) I think there is an easy way to fix it by checking for dedicated =
 > t instead of dedicated != nil inside get-lru-window and
 > get-largest-window (by the way, is there any chance those are
 > implemented in Lisp?).

They are implemented in ELisp on the window-pub branch.

 >> If the window is dedicated for the sole purpose to make it disappear
 >> when it's no more need I tend to agree.  There are better solutions.
 >
 > Please tell which.

Use a window parameter say `delete-window-when-buffer-is-buried'.  When
a window is created by `display-buffer', right after the
`set-window-buffer' call, set the parameter to the buffer argument.  In
`bury-buffer', `replace-buffer-in-windows', ... if the parameter value
of `delete-window-when-buffer-is-buried' equals the buffer of the
window, delete the window if possible.  Look at the quit-restore
parameter in the window-pub branch.

 > The minibuffer.el 's completion mechanism does not impose any
 > restrictions on what you can do while *Completions* is visible. That's
 > slightly off-topic, but I think it allows more user freedom and
 > clearer code.

If that's the case you can do away with the completions window whenever
you want to.  I see little difference between deleting the completions
window manually and having `display-buffer' use it for showing another
buffer.

 >> The _only_ purpose of weakly dedicated windows is to not allow
 >> `display-buffer' to use them.
 >
 > I disagree. As a matter of fact, weakly dedicated windows possess
 > another property: they are deleted when their buffer is killed.
 >
 > As a matter of personal opinion, "not allow `display-buffer' to use
 > them, but allow `set-window-buffer' to use them" is very hard concept
 > to understand. Especially given that `display-buffer' uses
 > `set-window-buffer' inside ;-) Even harder to understand is the
 > distinction between weakly and truly dedication.

The distinction is that the _user_ should be allowed to reuse a weakly
dedicated window, for example, when switching buffers in the selected
window.  Application programs should not be allowed to use them.

 >> IIUC the sequence of events is
 >>
 >> (1) the application issues a call for getting the name of a buffer,
 >>
 >> (2) the user enters the name with the assistance of the completion
 >>    routines,
 >>
 >> (3) the completion routines return the name,
 >>
 >> (4) the caller displays the buffer with that name.
 >>
 >
 > No. The command showing *Completions* and command calling
 > display-buffer are totally unrelated. See the first message.

This doesn't make sense to me.  I consider popping up a completions
window and subsequently deleting it one user interaction that should not
be disrupted by other activities like displaying some unrelated buffer.

martin

bug#7368: display-buffer a softly dedicated window

[Андрей Парамонов]

2010/11/18 martin rudalics <rudalics@gmx.at>:
> They are implemented in ELisp on the window-pub branch.
> ...
> Use a window parameter say `delete-window-when-buffer-is-buried'.  When
> a window is created by `display-buffer', right after the
> `set-window-buffer' call, set the parameter to the buffer argument.  In
> `bury-buffer', `replace-buffer-in-windows', ... if the parameter value
> of `delete-window-when-buffer-is-buried' equals the buffer of the
> window, delete the window if possible.  Look at the quit-restore
> parameter in the window-pub branch.

Now I'm tempted to try out that branch. What is the best way to do so?

> If that's the case you can do away with the completions window whenever
> you want to.  I see little difference between deleting the completions
> window manually and having `display-buffer' use it for showing another
> buffer.

Deleting *Completions* manually requires a keystroke, and more
importantly, remembering to do that keystroke. Every time when I wish
to switch to interpreter. That's very disruptive!

> The distinction is that the _user_ should be allowed to reuse a weakly
> dedicated window, for example, when switching buffers in the selected
> window.  Application programs should not be allowed to use them.

Now I think see your point.

>> No. The command showing *Completions* and command calling
>> display-buffer are totally unrelated. See the first message.
>
> This doesn't make sense to me.  I consider popping up a completions
> window and subsequently deleting it one user interaction that should not
> be disrupted by other activities like displaying some unrelated buffer.

Well, maybe my workflow is not typical, but I find it effective:

1) Write code.

2) Run it.

3) Write more code.

4) To inspect what methods an object has, hit M-Tab.

5) Look, scratch head ;-)

6) In a burst of inspiration, quickly switch to interpreter to inspect
a field of an object.

7) Switch back to the code buffer.

8) goto 1)

Everything except 1, 2, 5 should need only muscle memory, no thinking.
Hope you understand what I mean.

Best wishes,
Andrey Paramonov

bug#7368: display-buffer a softly dedicated window

[martin rudalics]

 > Now I'm tempted to try out that branch. What is the best way to do so?

I never tried but if you checked out the trunk with bzr something like

  bzr branch bzr://bzr.savannah.gnu.org/emacs/window-pub window-pub

in the directory of your shared emacs repository should work.  I don't
know how to work with the git mirror.

[...]
 > 6) In a burst of inspiration, quickly switch to interpreter to inspect
 > a field of an object.

And here you want the completions window show the interpreter?

 > 7) Switch back to the code buffer.

But here you've lost the completions window.

 > 8) goto 1)
 >
 > Everything except 1, 2, 5 should need only muscle memory, no thinking.
 > Hope you understand what I mean.

Why don't you use three windows in your workflow?

martin

bug#7368: display-buffer a softly dedicated window

[Андрей Парамонов]

2010/11/18 martin rudalics <rudalics@gmx.at>:
> I never tried but if you checked out the trunk with bzr something like
> bzr branch bzr://bzr.savannah.gnu.org/emacs/window-pub window-pub

Thanks, I'll try it soon and report the results.

>> 6) In a burst of inspiration, quickly switch to interpreter to inspect
>> a field of an object.
>
> And here you want the completions window show the interpreter?

comint.el forces *Completions* to close and shows the interpreter
immediately, in its place. That's what I want, exactly. Showing the
interpreter in place of *Completions* would have the same effect, so
it's what I want, too.

>> 7) Switch back to the code buffer.
>
> But here you've lost the completions window.

Yes, but that's no problem as I'll be able to quickly resurrender it
by hitting M-Tab.

> Why don't you use three windows in your workflow?

My code window occupies full frame most of the time. That allows me to
see more code.

Best wishes,
Andrey Paramonov

bug#7368: display-buffer a softly dedicated window

[martin rudalics]

 > comint.el forces *Completions* to close and shows the interpreter
 > immediately, in its place. That's what I want, exactly. Showing the
 > interpreter in place of *Completions* would have the same effect, so
 > it's what I want, too.

I've looked into comint.el.  It's apparently based on window
configurations and restores the old configuration when you do
`choose-completion' or type SPACE.  I don't see where it deletes the
window when you do something else.  Very contrived code.

 > My code window occupies full frame most of the time. That allows me to
 > see more code.

Hm...  What about setting `display-buffer-function' to something like:

(defun my-display-buffer (buffer flag)
   (let (window display-buffer-function)
     (when (and (= (length (window-list)) 2)
	       (setq window (get-buffer-window "*Completions*")))
       (set-window-dedicated-p window nil))
     (display-buffer buffer flag)))

martin

bug#7368: display-buffer a softly dedicated window

[Андрей Парамонов]

2010/11/18 martin rudalics <rudalics@gmx.at>:
>> comint.el forces *Completions* to close and shows the interpreter
>> immediately, in its place. That's what I want, exactly. Showing the
>> interpreter in place of *Completions* would have the same effect, so
>> it's what I want, too.
>
> I've looked into comint.el.  It's apparently based on window
> configurations and restores the old configuration when you do
> `choose-completion' or type SPACE.  I don't see where it deletes the
> window when you do something else.  Very contrived code.

If you are interested you may check the example I provided in my
recent emacs.devel thread. *Completions* is somehow closed before
comint-dynamic-list-completions is finished
(comint-dynamic-list-completions doesn't exit immediately upon showing
*Completions*).

> Hm...  What about setting `display-buffer-function' to something like:
>
> (defun my-display-buffer (buffer flag)
>  (let (window display-buffer-function)
>    (when (and (= (length (window-list)) 2)
>               (setq window (get-buffer-window "*Completions*")))
>      (set-window-dedicated-p window nil))
>    (display-buffer buffer flag)))
>

Hm, nice idea. But isn't display-buffer-function called from
display-buffer (infinite recursion)? I'll check it when I get to my
Emacs box.

Best wishes,
Andrey Paramonov

bug#7368: display-buffer a softly dedicated window

[martin rudalics]

 > Hm, nice idea. But isn't display-buffer-function called from
 > display-buffer (infinite recursion)? I'll check it when I get to my
 > Emacs box.

Whenever you call `display-buffer' from `display-buffer-function'
make sure that you've bound the latter to nil around the call.

martin

bug#7368: display-buffer a softly dedicated window

[Stefan Monnier]

> Deleting *Completions* manually requires a keystroke, and more
> importantly, remembering to do that keystroke. Every time when I wish
> to switch to interpreter. That's very disruptive!

Maybe the fact that *Completions* is still shown at this point is
a bug.  If I were you, I'd focus on this point first.


        Stefan

bug#7368: display-buffer a softly dedicated window

[Lennart Borgman]

2010/11/17 Stefan Monnier <monnier@iro.umontreal.ca>:
>
> This is irrelevant because calling switch-to-buffer from Elisp is a bug
> in my book.

Which book is that? (I thought the elisp manual was yours.)

bug#7368: display-buffer a softly dedicated window

[Андрей Парамонов]

I've checked out window-pub and played with it bit. Basically,
everything worked great for me so far (note: I use default window
options). Didn't notice any regressions. The problem with
*Completions* is gone because in window-pub *Completions* is not
dedicated :-)  Also, I liked that many functions moved from C to Lisp
(one can explore and tweak them much easier).

As a temporary solution to the bug I now use the following code. It
has some minor issues (i.e. if *Completions* is above code buffer, and
I switch to interpreter, code buffer would come above and interpreter
buffer would come below), but I can definitely live with it. However,
proper upstream fix would still be very welcome.

(defun my-display-buffer (buffer flag)
  (when (not (eq (buffer-name buffer) "*Completions*"))
    (let ((completions-window (get-buffer-window "*Completions*")))
      (when completions-window
	(quit-window nil completions-window))))
  (let (display-buffer-function)
    (display-buffer buffer flag)))

(setq display-buffer-function 'my-display-buffer)

Thanks for your support,
Andrey Paramonov

bug#7368: display-buffer a softly dedicated window

[Glenn Morris]

Version: 24.1

> I've checked out window-pub and played with it bit. Basically,
> everything worked great for me so far (note: I use default window
> options). Didn't notice any regressions.

Since this branch was merged to the trunk, I am assuming this report can
now be closed.

bug#7368: display-buffer a softly dedicated window

[martin rudalics]

 > Since this branch was merged to the trunk, I am assuming this report can
 > now be closed.

So far only the routines in window.el have been merged.  The calling
routines are mostly the same, so this report is probably still valid.

martin

bug#7368: display-buffer a softly dedicated window

[Glenn Morris]

martin rudalics wrote:

>> Since this branch was merged to the trunk, I am assuming this report can
>> now be closed.
>
> So far only the routines in window.el have been merged.  The calling
> routines are mostly the same, so this report is probably still valid.

Do you plan to merge the rest of it, or ... ?

bug#7368: display-buffer a softly dedicated window

[martin rudalics]

 > Do you plan to merge the rest of it, or ... ?

Sure.  But the problems with *Completions* windows still represent a
subject for further investigation as a recent thread here shows.

martin

bug#7368: display-buffer a softly dedicated window

[Glenn Morris]

martin rudalics wrote:

>> Do you plan to merge the rest of it, or ... ?
>
> Sure.  But the problems with *Completions* windows still represent a
> subject for further investigation as a recent thread here shows.

OK, then I misunderstood and will reopen this.

bug#7368: display-buffer a softly dedicated window

[martin rudalics]

 >> Sure.  But the problems with *Completions* windows still represent a
 >> subject for further investigation as a recent thread here shows.
 >
 > OK, then I misunderstood and will reopen this.

The more recent changes to displaying the *Completions* window should
have made this report at least completely out-dated so I'm closing it.

martin