Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> Lars, any thoughts on how best to protect M-x from errors in
>> completion-predicate?  Is the following okay?
>
> [...]
>
>> +      (condition-case-unless-debug err
>> +          (funcall (get symbol 'completion-predicate) symbol buffer)
>> +        (error
>> +         (message "command-completion-default-include-p: %s: %S" symbol err)
>> +         nil))
>
> What's the performance impact here?  This is going to be called a whole
> bunch of times when the user hits TAB...

Compared to everything else going on around this, negligible.

Running the attached benchmark with

  emacs -Q -batch -f batch-byte-compile bench.el
  emacs -Q -l bench.elc

gives the following excerpts of timings:

  TAB RET
  bench-pred-expensive 1.804303 36 0.564483
  bench-pred-expensive 1.790578 35 0.551621
  bench-pred-expensive 1.777639 35 0.549471
  bench-pred-none      0.982336 35 0.550554
  bench-pred-none      0.980999 35 0.549281
  bench-pred-none      0.982774 35 0.550178
  bench-pred-old       0.834787 29 0.452026
  bench-pred-old       0.831663 29 0.450019
  bench-pred-old       0.830596 29 0.450292
  bench-pred-new       0.831019 29 0.450161
  bench-pred-new       0.831628 29 0.451437
  bench-pred-new       0.835570 29 0.452512

  e w w - TAB C-a C-k RET
  bench-pred-expensive 1.080096 30 0.413564
  bench-pred-expensive 1.078444 30 0.413685
  bench-pred-expensive 1.077938 30 0.414732
  bench-pred-none      1.003878 30 0.416143
  bench-pred-none      0.987872 30 0.413814
  bench-pred-none      0.991742 30 0.416257
  bench-pred-old       0.889184 25 0.343545
  bench-pred-old       0.889369 25 0.344027
  bench-pred-old       0.885496 25 0.343227
  bench-pred-new       0.901361 25 0.345625
  bench-pred-new       0.887233 25 0.344885
  bench-pred-new       0.889201 25 0.344515

Where bench-pred-new extends bench-pred-old with the suggested
condition-case-unless-debug in the "tight" loop.

> I'm also not quite sure why we should be ignoring these errors --
> they're code errors, like any others, and shouldn't be expected to
> fail, should they?

No, but code rarely listens to expectations ;).

Of course this use case isn't as critical/irreversible as
post-command-hook or process filters/sentinels, but the general notion
is similar: it would be nice if code errors didn't bork M-x completion.

-- 
Basil