From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Roland Winkler Newsgroups: gmane.emacs.devel Subject: Re: minibuffer-selected-buffer Date: Sat, 14 Jun 2003 12:26:47 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <16106.63591.273797.775882@tfkp07.physik.uni-erlangen.de> References: <16104.44805.593166.683026@tfkp07.physik.uni-erlangen.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1055586460 14996 80.91.224.249 (14 Jun 2003 10:27:40 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2003 10:27:40 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Jun 14 12:27:36 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19R8G0-0003td-00 for ; Sat, 14 Jun 2003 12:27:36 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19R8cP-0007aH-00 for ; Sat, 14 Jun 2003 12:50:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19R8GM-00058u-MX for emacs-devel@quimby.gnus.org; Sat, 14 Jun 2003 06:27:58 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19R8Fi-0004sI-FE for emacs-devel@gnu.org; Sat, 14 Jun 2003 06:27:18 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19R8FO-00049J-Gu for emacs-devel@gnu.org; Sat, 14 Jun 2003 06:27:00 -0400 Original-Received: from max6.rrze.uni-erlangen.de ([131.188.3.214]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19R8FK-0003wB-DQ; Sat, 14 Jun 2003 06:26:54 -0400 Original-Received: from tfkp07.physik.uni-erlangen.de by max6.rrze.uni-erlangen.de with ESMTP; Sat, 14 Jun 2003 12:26:51 +0200 Original-To: rms@gnu.org In-Reply-To: X-Mailer: VM 6.96 under Emacs 21.2.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:15094 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:15094 On Fri Jun 13 2003 Richard Stallman wrote: > The function minibuffer-selected-window returns the window which was > selected when entering the minibuffer. For bibtex.el I would like to > use a function minibuffer-selected-buffer that returns the buffer > which was the current buffer when entering the minibuffer. Would it > make sense to add such a function to emacs? > > The best practice is to call completing-read only to read arguments > to a command. The current buffer when the command is run > is the selected window's buffer. > > So it seems that (window-buffer (minibuffer-selected-window)) would do > the job. In what case is this not correct? ...Thank you! The more I think about it, it seems to me that (window-buffer (minibuffer-selected-window)) will do the job I need for bibtex.el. The point is that in my particular problem the generation of the completion table can be rather expensive. So Stefan suggested to me that the generation of the completion table should be delayed until it is really required because the user hits the TAB key. But then the function generating the completion table is called only once and it stores the completion table in a variable that is used afterwards. I think that for this one call of the function generating the completion table (window-buffer (minibuffer-selected-window)) will always be meaningful because it happens prior to any changes in the window configuration in order to display the completion buffer. However, I can imagine the following scenario (I don't know how frequent this might happen): Suppose that for a certain problem the completion table is always generated dynamically by calling an appropriate function. Usually, windows are split in order to display the completion buffer. However, I can imagine that a user wants to have only one window displayed that is showing the completions he can choose from. Of course, this requires that either the user explicitely deletes minibuffer-selected-window. Or it can happen that a small frame height allows only one window to be displayed. Roland