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