Re: Completion: minibuffer.el vs comint.el

[Andrew Helsley <helsleya@cs.ucr.edu>]

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
>