Re: Completion: minibuffer.el vs comint.el

Re: Completion: minibuffer.el vs comint.el

[Andrew Helsley]

Hi,

I think it may become dedicated in the function `minibuffer-completion-help'
in `minibuffer.el'. Notice the local binding of the variable 
`display-buffer-mark-dedicated'.  From the documentation of the variable:

 	If non-nil, `display-buffer' marks the windows it creates as dedicated.

`display-buffer' itself is called from the `with-output-to-temp-buffer' C
function (at least that is what `with-output-...'s docs suggest).

Unfortunately as for intent/reason behind this behavior, I don't have a clue.
There are some comments in the `minibuffer-completion-help' function that may
provide further insight.  Hopefully seeing where it makes the window dedicated
can help you find your reason or reasonably conclude that it can be safely be
changed to be more like comint.el.

--------
regards,
Andy


On Sun, 14 Nov 2010, cmr.pent@gmail.com wrote:

> Date: Sun, 14 Nov 2010 19:44:52 +0300
> From: ?????? ????????? 	<cmr.pent@gmail.com>
> Subject: Completion: minibuffer.el vs comint.el
> To: emacs-devel@gnu.org
> Cc: martin rudalics <rudalics@gmx.at>
> Message-ID:
> 	<AANLkTinrm12uLLEMbhb1yxRbzB+zQs77P0=m-Kiq84nE@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hello!
>
> I'm investigating possibilities to use Emacs Python IDE. Before I used
> Emacs for writing programs in R language, with the help of ESS
> package. Both ESS mode and Python mode have helper inferior modes to
> interact with interpreter. Also, both have very decent completion.
>
> I've found out that ESS mode completion works via comint.el 's
> comint-dynamic-complete, while Python mode (and, in fact, the majority
> of modes including Emacs Lisp mode and Semantic) completion works via
> minibuffer.el 's completion-at-point. Why bother, may you ask? In
> fact, I would never bother about internals and even wouldn't notice
> any difference if not subtle, but extremely annoying detail. It's
> about how display-buffer acts in presence of *Completions* buffer.
>
> To reproduce:
>
> 0) Make sure pop-up-frames is nil (the default).
>
> 1) comint.el completion (this required you to press a key in the
> middle of program -- it there a way to make this testcase fully
> automated?):
>
> (global-set-key [(f12)] '(lambda() (interactive)
> 			   (progn
> 			     (if (window-dedicated-p (get-buffer-window "*Completions*"))
> 				 (message "*Completions* is dedicated")
> 			       (message "*Completions* is NOT dedicated"))
> 			     (display-buffer "bar" t))))
>
> (require 'comint)
> (let ((foo (get-buffer-create "foo"))
>      (bar (get-buffer-create "bar")))
>  (switch-to-buffer foo)
>  (delete-other-windows)
>  (comint-dynamic-list-completions (list "alice" "anastasia" "anna"))
>  ;; The following display-buffer call is impossible because we want
>  ;; to display-buffer while *Completions* is visible. Press F12.
>  ;; (display-buffer bar t)
>  )
>
> On pressing F12, you will see buffer "bar" open in place of
> *Completions* window. This is the expected thing, actually.
>
> 2) minibuffer.el completion:
>
> (let ((foo (get-buffer-create "foo"))
>      (bar (get-buffer-create "bar")))
>  (switch-to-buffer foo)
>  (delete-other-windows)
>  (emacs-lisp-mode)
>  (insert "(a")
>  (completion-at-point)
>  (if (window-dedicated-p (get-buffer-window "*Completions*"))
>      (message "*Completions* is dedicated")
>    (message "*Completions* is NOT dedicated"))
>  (display-buffer bar t))
>
> You will see buffer "bar" open in a new frame despite pop-up-frames
> being nil (documentation says: if nil, never make a separate frame!).
> Also you will see why it happens: *Completions* window is "dedicated".
> This is damn annoying!
>
> I have limited experience in elisp so I can't understand why and where
> *Completions* buffer becomes dedicated (set-window-dedicated-p is a
> built-in function in `C source code' -- is there a way to set a
> breakpoint for it?). If it's intentional, is there a reason for it?
> comint.el doesn't set "dedicated" flag, and seems to work just fine.
>
> See also debbugs.gnu.org/7368 .
>
> Best wishes,
> Andrey Paramonov
>
>
>
> ------------------------------
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>

Re: Completion: minibuffer.el vs comint.el

[Stefan Monnier]

> I think it may become dedicated in the function `minibuffer-completion-help'
> in `minibuffer.el'. Notice the local binding of the variable
> display-buffer-mark-dedicated'.  From the documentation of the variable:

> 	If non-nil, `display-buffer' marks the windows it creates as dedicated.

> `display-buffer' itself is called from the `with-output-to-temp-buffer' C
> function (at least that is what `with-output-...'s docs suggest).

> Unfortunately as for intent/reason behind this behavior, I don't have
> a clue.

This is so as to know whether to delete the window when the *Completions*
buffer is hidden/buried.

Maybe we should use another approach (hi Martin ;-).  E.g. just add
a flag "created for *Completions*" when we create the window, that would
work similarly to `dedicated' w.r.t bury-buffer but which would not
prevent display-buffer from reusing that window for some other buffer.


        Stefan

Re: Completion: minibuffer.el vs comint.el

[martin rudalics]

>> I think it may become dedicated in the function `minibuffer-completion-help'
>> in `minibuffer.el'. Notice the local binding of the variable
>> display-buffer-mark-dedicated'.  From the documentation of the variable:
>
>> 	If non-nil, `display-buffer' marks the windows it creates as dedicated.
>
>> `display-buffer' itself is called from the `with-output-to-temp-buffer' C
>> function (at least that is what `with-output-...'s docs suggest).
>
>> Unfortunately as for intent/reason behind this behavior, I don't have
>> a clue.
>
> This is so as to know whether to delete the window when the *Completions*
> buffer is hidden/buried.
>
> Maybe we should use another approach (hi Martin ;-).  E.g. just add
> a flag "created for *Completions*" when we create the window, that would
> work similarly to `dedicated' w.r.t bury-buffer but which would not
> prevent display-buffer from reusing that window for some other buffer.

The dedicated window method works well for displaying a buffer in a
separate frame or a new window.  It can't be used when a window is
reused for displaying the buffer.  In my branch `display-buffer' always
records the previous state and burying the buffer or quitting the window
conveniently restores the previous state.  So when you dedicate a window
to its buffer you exclusively do that because you do not want to display
another buffer in that window.

martin

Re: Completion: minibuffer.el vs comint.el

[Stefan Monnier]

> The dedicated window method works well for displaying a buffer in a
> separate frame or a new window.

But that's exactly what we do currently: mark the window dedicated if
and only if the window was created for this buffer.

> It can't be used when a window is reused for displaying the buffer.

Indeed we don't mark it dedicated when we reuse a window.

> In my branch `display-buffer' always records the previous state and
> burying the buffer or quitting the window conveniently restores the
> previous state.

Not sure what "state" this includes, so maybe it's a good idea, but
I haven't seen many complaints about the current behavior in this respect.


        Stefan

Re: Completion: minibuffer.el vs comint.el

[martin rudalics]

 >> The dedicated window method works well for displaying a buffer in a
 >> separate frame or a new window.
 >
 > But that's exactly what we do currently: mark the window dedicated if
 > and only if the window was created for this buffer.
 >
 >> It can't be used when a window is reused for displaying the buffer.
 >
 > Indeed we don't mark it dedicated when we reuse a window.
 >
 >> In my branch `display-buffer' always records the previous state and
 >> burying the buffer or quitting the window conveniently restores the
 >> previous state.
 >
 > Not sure what "state" this includes, so maybe it's a good idea, but
 > I haven't seen many complaints about the current behavior in this respect.

The previous "state" for a reused window is that window's buffer, window
start, and window point at the time it was replaced by `display-buffer'.
This amounts to all the things we currently restore when quitting a help
window.

martin

Re: Completion: minibuffer.el vs comint.el

[Stefan Monnier]

>> Not sure what "state" this includes, so maybe it's a good idea, but
>> I haven't seen many complaints about the current behavior in this respect.
> The previous "state" for a reused window is that window's buffer, window
> start, and window point at the time it was replaced by `display-buffer'.
> This amounts to all the things we currently restore when quitting a help
> window.

Window-start and window-point sound like good improvements over the
usual behavior of bury-buffer.


        Stefan

Completion: minibuffer.el vs comint.el

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

Hello!

I'm investigating possibilities to use Emacs Python IDE. Before I used
Emacs for writing programs in R language, with the help of ESS
package. Both ESS mode and Python mode have helper inferior modes to
interact with interpreter. Also, both have very decent completion.

I've found out that ESS mode completion works via comint.el 's
comint-dynamic-complete, while Python mode (and, in fact, the majority
of modes including Emacs Lisp mode and Semantic) completion works via
minibuffer.el 's completion-at-point. Why bother, may you ask? In
fact, I would never bother about internals and even wouldn't notice
any difference if not subtle, but extremely annoying detail. It's
about how display-buffer acts in presence of *Completions* buffer.

To reproduce:

0) Make sure pop-up-frames is nil (the default).

1) comint.el completion (this required you to press a key in the
middle of program -- it there a way to make this testcase fully
automated?):

(global-set-key [(f12)] '(lambda() (interactive)
			   (progn
			     (if (window-dedicated-p (get-buffer-window "*Completions*"))
				 (message "*Completions* is dedicated")
			       (message "*Completions* is NOT dedicated"))
			     (display-buffer "bar" t))))

(require 'comint)
(let ((foo (get-buffer-create "foo"))
      (bar (get-buffer-create "bar")))
  (switch-to-buffer foo)
  (delete-other-windows)
  (comint-dynamic-list-completions (list "alice" "anastasia" "anna"))
  ;; The following display-buffer call is impossible because we want
  ;; to display-buffer while *Completions* is visible. Press F12.
  ;; (display-buffer bar t)
  )

On pressing F12, you will see buffer "bar" open in place of
*Completions* window. This is the expected thing, actually.

2) minibuffer.el completion:

(let ((foo (get-buffer-create "foo"))
      (bar (get-buffer-create "bar")))
  (switch-to-buffer foo)
  (delete-other-windows)
  (emacs-lisp-mode)
  (insert "(a")
  (completion-at-point)
  (if (window-dedicated-p (get-buffer-window "*Completions*"))
      (message "*Completions* is dedicated")
    (message "*Completions* is NOT dedicated"))
  (display-buffer bar t))

You will see buffer "bar" open in a new frame despite pop-up-frames
being nil (documentation says: if nil, never make a separate frame!).
Also you will see why it happens: *Completions* window is "dedicated".
This is damn annoying!

I have limited experience in elisp so I can't understand why and where
*Completions* buffer becomes dedicated (set-window-dedicated-p is a
built-in function in `C source code' -- is there a way to set a
breakpoint for it?). If it's intentional, is there a reason for it?
comint.el doesn't set "dedicated" flag, and seems to work just fine.

See also debbugs.gnu.org/7368 .

Best wishes,
Andrey Paramonov