something between try-completion and test-completion?

something between try-completion and test-completion?

[Drew Adams]

I'd be interested in a function similar to both `try-completion' and
`test-completion', but which would just test whether its STRING arg can be
completed against its COLLECTION arg, respecting its PREDICATE arg.

It would be like `test-completion', in that as soon as some match is found
it would return non-nil, not bothering to test the other completions and
calculate the common prefix.

It would be like `try-completion', in that it would test whether the STRING
is a prefix of some COLLECTION element, not whether STRING is itself one of
the COLLECTION elements.

The idea is to have a quick version of `try-completion' for situations where
the common prefix of all matches is not needed, and all you want is an
indication of whether the STRING could be completed.

Any other interest in this? Any chance this will become available?

Re: something between try-completion and test-completion?

[Stefan Monnier]

> I'd be interested in a function similar to both `try-completion' and
> `test-completion', but which would just test whether its STRING arg can be
> completed against its COLLECTION arg, respecting its PREDICATE arg.

> It would be like `test-completion', in that as soon as some match is found
> it would return non-nil, not bothering to test the other completions and
> calculate the common prefix.

> It would be like `try-completion', in that it would test whether the STRING
> is a prefix of some COLLECTION element, not whether STRING is itself one of
> the COLLECTION elements.

> The idea is to have a quick version of `try-completion' for situations where
> the common prefix of all matches is not needed, and all you want is an
> indication of whether the STRING could be completed.

> Any other interest in this? Any chance this will become available?

Could you give us some sample situation where there'd be an actual
benefit (as in measurable performance difference) between try-completion
and the function you're looking for?


        Stefan


PS: Maybe you can hack it up by hand:

  (defun try-completion-p (string collection &optional predicate)
    (lexical-let ((predicate predicate))
      (catch 'tcp-found
        (try-completion string collection
                        (lambda (x)
                          (if (funcall predicate) (throw 'tcp-found t))))
        nil)))

RE: something between try-completion and test-completion?

[Drew Adams]

> > I'd be interested in a function similar to both `try-completion' and
> > `test-completion', but which would just test whether its 
> > STRING arg can be completed against its COLLECTION arg,
> > respecting its PREDICATE arg.
> 
> > It would be like `test-completion', in that as soon as some 
> > match is found it would return non-nil, not bothering to test
> > the other completions and calculate the common prefix.
> 
> > It would be like `try-completion', in that it would test 
> > whether the STRING is a prefix of some COLLECTION element,
> > not whether STRING is itself one of the COLLECTION elements.
> 
> > The idea is to have a quick version of `try-completion' for 
> > situations where the common prefix of all matches is not needed,
> > and all you want is an indication of whether the STRING could be
> > completed.
> 
> > Any other interest in this? Any chance this will become available?
> 
> Could you give us some sample situation where there'd be an actual
> benefit (as in measurable performance difference) between 
> try-completion and the function you're looking for?

No. I can't compare performance for a non-existent implementation. ;-)

If there are lots of completions for STRING, and there is a common prefix,
then `try-completion' will do extra work to find all the completions and
calculate that common prefix.

The point is that that extra work is, well, extra - not useful in this
context. What the performance difference would be by avoiding that
computation I can't predict.

But you can see that that work is not necessary, and you can imagine that,
in the case of many, many completions with a common prefix, that wasted time
could be important. How many completions would make it noticeable? And
noticeable in what contexts? I don't know (or care).

> PS: Maybe you can hack it up by hand:
> 
>   (defun try-completion-p (string collection &optional predicate)
>     (lexical-let ((predicate predicate))
>       (catch 'tcp-found
>         (try-completion string collection
>                         (lambda (x)
>                           (if (funcall predicate)
>                               (throw 'tcp-found t))))
>         nil)))

That does nothing in the (more typical) case where predicate is nil.

But that's the idea - have a function `try-completion-p' (or
`any-completions-p') that would stop as soon as it found one match (and not
just with PREDICATE).

Re: something between try-completion and test-completion?

[Stefan Monnier]

>> Could you give us some sample situation where there'd be an actual
>> benefit (as in measurable performance difference) between
>> try-completion and the function you're looking for?

> No. I can't compare performance for a non-existent implementation. ;-)

Of course you can.

> But you can see that that work is not necessary, and you can imagine
> that, in the case of many, many completions with a common prefix, that
> wasted time could be important.  How many completions would make it
> noticeable? And noticeable in what contexts? I don't know (or care).

Then I see no need for your function.


        Stefan

Re: something between try-completion and test-completion?

[Richard Stallman]

We're not interested in writing, or even discussing, a new function
whose only benefit is better performance unless there is a
demonstrated need.  We have a lot of bugs to fix now.

Please drop the subject.