From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: [harder@ifa.au.dk: Speed of all-completions] Date: Tue, 15 Jun 2004 10:42:36 -0500 (CDT) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200406151542.i5FFgaG25896@raven.dms.auburn.edu> References: NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1087314323 3299 80.91.224.253 (15 Jun 2004 15:45:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 15 Jun 2004 15:45:23 +0000 (UTC) Cc: schwab@suse.de, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jun 15 17:45:16 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BaG7g-0003kI-00 for ; Tue, 15 Jun 2004 17:45:16 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BaG7g-0002TP-00 for ; Tue, 15 Jun 2004 17:45:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BaG8c-0002rv-Pm for emacs-devel@quimby.gnus.org; Tue, 15 Jun 2004 11:46:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BaG8G-0002gR-U3 for emacs-devel@gnu.org; Tue, 15 Jun 2004 11:45:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BaG8F-0002fw-J8 for emacs-devel@gnu.org; Tue, 15 Jun 2004 11:45:52 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BaG8F-0002fl-Hb for emacs-devel@gnu.org; Tue, 15 Jun 2004 11:45:51 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BaG6f-0003YL-1l; Tue, 15 Jun 2004 11:44:13 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id i5FFi6uE018201; Tue, 15 Jun 2004 10:44:06 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.6+Sun/8.11.6) id i5FFgaG25896; Tue, 15 Jun 2004 10:42:36 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: dak@gnu.org In-reply-to: (message from David Kastrup on 15 Jun 2004 15:27:53 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:25002 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25002 David Kastrup wrote: To illustrate what I mean, here is a patch against the most recent version. Note that I have to undo the binding before calling a user-defined predicate function (which might rely on the original binding). The last of your three changes, not running in a loop, was not improvable, however. I believe it is a programmer defined predicate function. The obvious alternative to your patch would be to have case-fold-search bound to the value of completion-ignore-case around the entire while loops. The difference with the current situation would be that the binding would be in effect during the call to the predicate function. I believe that the result of the predicate function should not depend on a value which the user customized for a completely unrelated reason, interactive convenience. So the binding probably _should_ be in effect during the call to PREDICATE. If we decide to bind around the entire while loop we should document the fact that the binding is in effect during the call to predicate in the Elisp manual. In that case, the `if (CONSP (Vcompletion_regexp_list))' should be removed, and for consistency, the scope should also be extended in Ftest_completion. Is one single prolonged binding using specbind expensive or was the efficiency problem completely caused by the fact that it was used countless times in a loop? Sincerely, Luc.