emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: Speed of all-completions]


From: Luc Teirlinck
Subject: Re: address@hidden: Speed of all-completions]
Date: Mon, 14 Jun 2004 19:04:47 -0500 (CDT)

David Kastrup wrote:
   
   Andreas Schwab <address@hidden> writes:

   > This is due to this change:
   > 
   >    (Ftry_completion, Fall_completions, Ftest_completion): Bind
   >    case-fold-search to the value of completion-ignore-case when
   >    checking completion-regexp-list.
   > 
   > I've checked in a fix that avoids the overhead of specbind when
   > completion-regexp-list is empty.

   At the cost of being more expensive when it isn't.  I don't see why
   you have to undo the binding all the time.  Just initialize the
   binding depth variable to something illegal at the start of the
   function.  Then when you need the binding, you check whether it has
   already been done and do it if needed.

   And at the exit of the function, you check whether the binding had
   happened and in that case undo it before returning.

I believe that it is completely safe to bind case-fold-search to the
value of completion-ignore-case _once_ around the entire while loops
in Ftry_completion and Fall_completions.  No minibuffer is entered, so
there is no need to restore any user customized value of
case-fold-search.  I do not see the problem in Ftest_completion,
because the binding seems to be made only once there anyway.

For the moment, I have just taken a quick look.  I could double-check
this in more detail if that is what we want to do.

I believe I was just excessively conservative when I committed the
original patch, because I did not realize just how expensive specbind
was.

Note that there is only one single place in the entire Emacs C and
Lisp code where completion-regexp-list is non-nil, namely in
customize-mode.  So it is definitely more important to optimize in the
case where it is nil, than in the case where it is not.

Sincerely,

Luc.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]