Re: A dynamic pattern-matching

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> - it'd be easy to write a variant of icomplete-mode that addresses
>> point 1 by using a separate buffer (which we'd call
>> "*Completions*").

> Well, that's not clear to me. IIUC completing-read and other functions
> of that kind blocks the calling program until the user makes up his
> mind, while my selector/select uses a callback.

> In fact, is it really desirable to use that selector in place of the
> standard completion functions ? My idea was more to provide an
> alternative to recentf-open-files and switch-buffer.

Yes, both issues relate to "point 6", i.e. the API.
Yours is non-modal (well, the minibuffer is not 100% modal, since you
can do something else while a minibuffer is open, especially if you set
enable-recursive-minibuffers, but it imposes a strict nesting).

The idea of integrating the two, is that users can then use yours
without changing the corresponding code to use your API.  Users could
choose which interaction mode to use for which commands.  Or even
provide a command to dynamically switch interaction mode directly from
the minibuffer.

>> - point 4 can be simulated by adding a "*" at the beginning of
>> the pattern.  Or we could add a `substring' completion-style.
> Yes. But I would vote for having a variable that specifies how the
> typed pattern has to be interpreted { substrings, regexp,
> leadingstring } or something.
>> - point 5 hopefully can be implemented as a completion-style.
> Not sure to understand what you do mean here.

To get a vague idea of what I'm talking about check
`completion-styles' as well as `completion-styles-alist'.


        Stefan