From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now Date: Wed, 25 Dec 2013 00:30:07 -0800 Message-ID: <52BA978F.4010804@dancol.org> References: <497ebd3d-d69b-4ac4-9d8c-ca2f4a1a2ac1@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1387960273 21952 80.91.229.3 (25 Dec 2013 08:31:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Dec 2013 08:31:13 +0000 (UTC) To: Drew Adams , 16251@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 25 09:31:18 2013 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 1Vvjs6-0008HU-Hs for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Dec 2013 09:31:18 +0100 Original-Received: from localhost ([::1]:41631 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vvjs6-00035J-3j for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Dec 2013 03:31:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vvjrx-000347-IA for bug-gnu-emacs@gnu.org; Wed, 25 Dec 2013 03:31:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vvjrr-0001df-5r for bug-gnu-emacs@gnu.org; Wed, 25 Dec 2013 03:31:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vvjrq-0001db-VY for bug-gnu-emacs@gnu.org; Wed, 25 Dec 2013 03:31:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vvjrq-0002u0-HE for bug-gnu-emacs@gnu.org; Wed, 25 Dec 2013 03:31:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Dec 2013 08:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16251 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16251-submit@debbugs.gnu.org id=B16251.138796021811065 (code B ref 16251); Wed, 25 Dec 2013 08:31:02 +0000 Original-Received: (at 16251) by debbugs.gnu.org; 25 Dec 2013 08:30:18 +0000 Original-Received: from localhost ([127.0.0.1]:40515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vvjr6-0002sO-IW for submit@debbugs.gnu.org; Wed, 25 Dec 2013 03:30:17 -0500 Original-Received: from dancol.org ([96.126.100.184]:47345) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vvjr2-0002sA-BR for 16251@debbugs.gnu.org; Wed, 25 Dec 2013 03:30:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=8x7VQNIG9Gu8uXvkA5kR1AjT1rXJkh5gIPUV9KoDK6U=; b=eWh+G1qZFJ5EN4XOZmEycMQbZs8oP73Q4fJ06DGlQuGWSsBMxRaZHTMRgHvp0+S9PguEqUqfmKSECToJAzdYN8tlDDJFhii7xUsPjR/hRmhXRrRDMm8Ojp2clHP4+x7kvxqG/+Z7Xaal6qjwJn/58PcSCLUJezDr1wsFuNFM7p9MD0MYcYPkyPhcayii9O7TCkrpNwGbzabrxVINd8ACSE6kokPKGUFfVt8XsmFULfdcO1NzJCYFswCw7tHiyA6U1qSAzWWwq+xZzNz2TGmsj69v6tGgWwiS+uhOTaet7FYFKdO5ielbNfou88dTVWkq7bH/poheDrnIZpbYRgrPRg==; Original-Received: from c-76-22-66-162.hsd1.wa.comcast.net ([76.22.66.162] helo=[192.168.1.100]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Vvjr0-00015v-Nh; Wed, 25 Dec 2013 00:30:10 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <497ebd3d-d69b-4ac4-9d8c-ca2f4a1a2ac1@default> 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:82574 Archived-At: On 12/24/2013 09:58 PM, Drew Adams wrote: > [The build noted below is the one this bug report is for. But I'm > sending this using an older build than the one noted below, because of > another new bug, which prevents using `report-emacs-bug'] > > > Just a preliminary heads up for now. Hope to add more info later, when > I get some time. > > I downloaded this build, and when `icomplete-mode' is on, with my setup > it takes several seconds to gather the list of file candidates in my > usual directory. With a build from two days ago, this does not happen. > And if I turn off icomplete mode it also does not happen. > > It seems that something was changed in the icomplete mode code recently > that breaks at least my file-finding code. > > With emacs -Q I do not notice the problem (well, maybe a slight delay). > I see that C-x C-f now shows completions immediately, without my typing > any prefix. That is not true in the build from 2 days ago. Mea culpa: I committed a change that caused icomplete to try to show completions right away by default. As Jambunathan mentions, setting icomplete-show-matches-on-no-input to nil should restore the old behavior. The old behavior isn't optimal, though, and icomplete isn't a replacement for iswitchb without the feature I added. Maybe we can change icomplete-show-matches-on-no-input to a command list --- this way, we could show completions early for buffer switching, but not for finding files. Why is finding the list of files so slow for you? Don't you experience the same performance problem after typing a character and forcing completions to show up? We call the completion function inside while-no-input, so we should abort the "several seconds" of work as soon as you start typing.