From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andrew Helsley Newsgroups: gmane.emacs.devel Subject: Re: Completion: minibuffer.el vs comint.el Date: Mon, 15 Nov 2010 13:56:19 -0800 (PST) Message-ID: References: <20101114173358.683A6628353@mail.cs.ucr.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Trace: dough.gmane.org 1289858287 19088 80.91.229.12 (15 Nov 2010 21:58:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 15 Nov 2010 21:58:07 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 15 22:58:03 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PI73l-00029X-Vu for ged-emacs-devel@m.gmane.org; Mon, 15 Nov 2010 22:57:58 +0100 Original-Received: from localhost ([127.0.0.1]:34519 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PI73l-0004u0-IA for ged-emacs-devel@m.gmane.org; Mon, 15 Nov 2010 16:57:57 -0500 Original-Received: from [140.186.70.92] (port=43596 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PI73O-0004ms-Lu for emacs-devel@gnu.org; Mon, 15 Nov 2010 16:57:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PI73K-0007GB-Ou for emacs-devel@gnu.org; Mon, 15 Nov 2010 16:57:34 -0500 Original-Received: from mail.cs.ucr.edu ([138.23.169.83]:44966) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PI73K-0007FM-Ft for emacs-devel@gnu.org; Mon, 15 Nov 2010 16:57:30 -0500 Original-Received: from mail.cs.ucr.edu (localhost.localdomain [127.0.0.1]) by mail.cs.ucr.edu (Postfix) with ESMTP id 75781628196 for ; Mon, 15 Nov 2010 13:56:24 -0800 (PST) Original-Received: by mail.cs.ucr.edu (Postfix, from userid 202) id 6A3CB6287F3; Mon, 15 Nov 2010 13:56:24 -0800 (PST) Original-Received: from eon.cs.ucr.edu (eon.cs.ucr.edu [138.23.169.9]) by mail.cs.ucr.edu (Postfix) with ESMTP id B423A628196 for ; Mon, 15 Nov 2010 13:56:19 -0800 (PST) In-Reply-To: <20101114173358.683A6628353@mail.cs.ucr.edu> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) X-Virus-Scanned: ClamAV using ClamSMTP X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:132668 Archived-At: 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: ?????? ????????? > Subject: Completion: minibuffer.el vs comint.el > To: emacs-devel@gnu.org > Cc: martin rudalics > Message-ID: > > 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 >