From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#19457: 24.4; exec_sentinel_error_handler and read_process_output_error_handler Date: Thu, 01 Jan 2015 11:29:09 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1420129819 27372 80.91.229.3 (1 Jan 2015 16:30:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Jan 2015 16:30:19 +0000 (UTC) Cc: 19457@debbugs.gnu.org To: Leo Liu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 01 17:30:11 2015 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 1Y6idV-0006ar-QB for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Jan 2015 17:30:09 +0100 Original-Received: from localhost ([::1]:48991 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y6idV-0002TI-9D for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Jan 2015 11:30:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y6idS-0002S6-Gt for bug-gnu-emacs@gnu.org; Thu, 01 Jan 2015 11:30:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y6idP-0006cy-7v for bug-gnu-emacs@gnu.org; Thu, 01 Jan 2015 11:30:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53457) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y6idP-0006cs-50 for bug-gnu-emacs@gnu.org; Thu, 01 Jan 2015 11:30:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y6idO-00046h-JZ for bug-gnu-emacs@gnu.org; Thu, 01 Jan 2015 11:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Jan 2015 16:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19457 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19457-submit@debbugs.gnu.org id=B19457.142012975415711 (code B ref 19457); Thu, 01 Jan 2015 16:30:02 +0000 Original-Received: (at 19457) by debbugs.gnu.org; 1 Jan 2015 16:29:14 +0000 Original-Received: from localhost ([127.0.0.1]:34590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y6icc-00045K-Hl for submit@debbugs.gnu.org; Thu, 01 Jan 2015 11:29:14 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:43347) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y6ica-00045C-Vq for 19457@debbugs.gnu.org; Thu, 01 Jan 2015 11:29:13 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t01GTABj031720; Thu, 1 Jan 2015 11:29:11 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 3AF2FAE130; Thu, 1 Jan 2015 11:29:09 -0500 (EST) In-Reply-To: (Leo Liu's message of "Sun, 28 Dec 2014 22:54:03 +1100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5173=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5173> : inlines <1719> : streams <1366499> : uri <1840835> 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:97918 Archived-At: > See completion--some; all errors are deferred to the end of the > function. There is no way a completion table can tell completion--some > "I am not ready" don't call me again. For example, when a completion > table involves running an external command and that command is not > installed in the system. In this case the completion table knows better > i.e. no need to retry so as to save precious time. [ I understand this may not really solve your problem, but it might still help you find the right solution: ] The repetition between the different calls to the completion-table happening during completion--some is expected to be avoided (if problematic) via caching. Back then I tried to come up with some alternative API that would provide directly the ability to share more work, but couldn't come up with anything that was really better than just using straight caching in the backend. Stefan