From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#16943: 24.3.50; [PATCH] `icomplete-exhibit' needs `with-current-buffer' for minibuffer Date: Fri, 7 Mar 2014 17:40:20 -0800 (PST) Message-ID: <740624be-841d-4560-81b8-367599f26c05@default> References: <5d97809c-5fbf-4b3e-b864-8badfbd532da@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1394242878 23935 80.91.229.3 (8 Mar 2014 01:41:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Mar 2014 01:41:18 +0000 (UTC) Cc: 16943@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 08 02:41:24 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WM6GQ-0000Fz-OQ for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Mar 2014 02:41:22 +0100 Original-Received: from localhost ([::1]:39019 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WM6GQ-0000Sm-5k for geb-bug-gnu-emacs@m.gmane.org; Fri, 07 Mar 2014 20:41:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WM6GF-0000Se-RY for bug-gnu-emacs@gnu.org; Fri, 07 Mar 2014 20:41:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WM6G7-0002Cx-8Q for bug-gnu-emacs@gnu.org; Fri, 07 Mar 2014 20:41:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54204) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WM6G7-0002Ct-4e for bug-gnu-emacs@gnu.org; Fri, 07 Mar 2014 20:41:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WM6G6-0004Jd-Fc for bug-gnu-emacs@gnu.org; Fri, 07 Mar 2014 20:41:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Mar 2014 01:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16943 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 16943-submit@debbugs.gnu.org id=B16943.139424283116516 (code B ref 16943); Sat, 08 Mar 2014 01:41:02 +0000 Original-Received: (at 16943) by debbugs.gnu.org; 8 Mar 2014 01:40:31 +0000 Original-Received: from localhost ([127.0.0.1]:55386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WM6Fa-0004II-H7 for submit@debbugs.gnu.org; Fri, 07 Mar 2014 20:40:30 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:37856) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WM6FW-0004Hz-0P for 16943@debbugs.gnu.org; Fri, 07 Mar 2014 20:40:26 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s281eMon007762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Mar 2014 01:40:23 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s281eLlF004974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Mar 2014 01:40:22 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s281eLCc021441; Sat, 8 Mar 2014 01:40:21 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:86648 Archived-At: > > (with-current-buffer (window-buffer (active-minibuffer-window)) >=20 > I think this would only paper over an underlying problem: icomplete uses > a buffer-local post-command-hook, so it makes no sense that it would be > run in another buffer. `icomplete-exhibit' should not use a buffer other than the minibuffer. But it apparently does sometimes. Hence the fix: confine it to the minibuffer. (FWIW, it is text like this that gets picked up from *Completions*: "Click on a completion to select it.") IIRC, Icomplete started out using the minibuffer, but (in the same (or perhaps a recursive?) minibuffer activation) it later was using *Completions*. I've kind of forgotten just how I was reproducing this. > A few possibilities: > > - the hook is placed in the wrong buffer, in which case it would > only be run in the wrong buffer. ^^^^ Clearly the minibuffer, not *Completions*, is the current buffer for *most* invocations of `icomplete-exhibit'. Otherwise, it would not work in general. It is not run *only* in the wrong buffer, for sure. > - an earlier post-command-hook function changed current-buffer. > - an earlier minibuffer-setup-hook function changed current-buffer > (which would cause the hook to be placed in the wrong buffer). Even if such were the case, for whatever reason, `icomplete-exhibit' should act on the text in the minibuffer. It should look to the minibuffer to do its job, regardless of whether some other buffer happens to be current when it is invoked. If the minibuffer is active then its input text is there for Icomplete to read and complete. You have said that `icomplete-exhibit' should not be invoked unless the minibuffer is current. Maybe so. But maybe not. In the case of my fix it now does the right thing: even if invoked with *Completions* current, it picks up text from the minibuffer. Would you instead have it do nothing in that case (e.g., by=20 preventing from being invoked)? Icomplete should complete minibuffer text, and so should be confined to the minibuffer. That does not imply that it should be invoked only from the minibuffer, i.e., only when the minibuffer is the current buffer. That would be a stronger constraint, whose necessity is not demonstrated. What is necessary and sufficient is that it be able to do its job when the minibuffer is active. That's not the same thing as it being *invoked* only with the minibuffer as current buffer. In any case, `icomplete-exhibit', and the Icomplete code more generally, should not have a say in what other things might or might not do wrt `post-command-hook', including while the minibuffer is active. `icomplete-exhibit' is meant to operate in the minibuffer. Perhaps some other commands on `post-command-hook' do not have that constraint, and make sense regardless of the buffer. Enabling `icomplete-mode' should not prevent such commands from being invoked by `post-command-hook' just because the minibuffer might be active. It seems to me that the proposed fix is entirely appropriate: as long as the minibuffer is active, `icomplete-exhibit' can do its thing. It just needs to be limited to doing it in the minibuffer; that's all. Control of Icomplete should be limited to what it does. It should focus on the minibuffer. But that does not say anything about `post-command-hook' in general while the minibuffer is active. Feel free to debug this and come up with a different fix. But a priori I don't think that should involve "fixing" what other commands on `post-command-hook' might do wrt the current buffer.