RE: Imports / inclusion of s.el into Emacs

[Drew Adams]

> > Don't forget that completion can now use substring
> > and other kinds of matching.
> 
> You understand that substring completion fails as soon as the term is
> too generic? e.g "string", "regexp" or "list", the list is just a lot
> of noise.

No, I don't "understand" that.  I mean I don't agree.

My position is that there is no one-size-fits-all
answer wrt completion.  Completion can serve many,
many, many different purposes.  And different
matching methods offer different advantages for
different purposes.

I use substring matching (regexp actually, but
often the pattern is, in effect, a substring)
very, very often.  And I can change among
different match methods instantly - nothing ties
me down to using substring matching, at all.

The domain (search space) for any given completion
is a set of completion candidates.  This set is
defined before you input anything.  The definition
can come from anything/anywhere, in any way.

For completion of buffer text (e.g. code) it
typically comes from text immediately before point.
For a help command (e.g. `C-h f') it might come
from the symbols that fit certain criteria (e.g.
have a function definition).

So already there is "matching" in some sense.

`completing-read', for example, can define a set
of candidates using a PREDICATE argument.  All
built-in functions that accept exactly one arg?
This predicate should do that job:

(defun unary-subr-p (f)
  (let* ((fun  (symbol-function f))
         (ar   (and fun
                    (ignore-errors (subr-arity fun)))))
    (and ar  (eql 1 (car ar))  (eql 1 (cdr ar)))))

(completing-read "Unary subr: " obarray 'unary-subr-p)

A particular set of candidates is defined, and you
can use completion just to examine that set, if
you want.  (There are 345 of them in my session.)

And if you have an interesting completion UI you
can perhaps selectively act on one or more of
those candidates.  You can perhaps show some info
(e.g. help/definition) about specific candidates.

E.g., perhaps cycling among function-name
candidates shows you the first line of their doc
strings in the mode-line of buffer `*Completions',
one by one.  Or maybe it shows you their complete
doc strings in `*Help*'.  Or if the candidates
are file names, maybe it shows you info about the
individual files as you cycle among them.

Or perhaps your UI lets you act on the set as a
whole in some way, e.g. print it, check out all
of the files, ... whatever.

This is all still without any matching of input
that you provide.  Completion is about using a
_set_ of things (names, but behind names, things
they name).

Then, you can of course provide input to _match_
against those domain candidates, to narrow the
field, giving a new, smaller set to play with.

But you can do the same kinds of things with
that new set: examine members, get info about
them, maybe act on them, individually or as a
set, in specific or arbitrary ways.

Provide a regexp or substring pattern to match,
et voila!  You've got "apropos" filtering of
candidate names.  And if your completion UI
gives you help/info about individual candidates
then you get the "apropos" doc as well.

Some completion UIs let you can perform
general set operations: intersect the current
set of matches with one or more other candidate
sets, get the union of sets, complement (e.g.
wrt the domain or a previous filtering or a
previously saved candidates set),...

And yes,...(drum roll) typically you can also
just choose one element of the set, act on it
in some way, and exit completion.  A quick
in-&-out-burger.

That last action is what many people think of
as completion - nothing more.  And if that's
their only goal then they can easily think that
what's most important is always only speed of
action, small number of choices, etc.

IMO, that's just one small, but important, use
case for completion.

In sum, yes, I might want to see all of the
functions with `string' in their name.  And
seeing them, I might want to get more info
about some of them.  Or act on some of them
in other ways.  No matter how many there are.

Heck, I might even just want to see how many
functions have `string' or `regexp' in their
name - e.g., to consider a question about
possible renamings... ;-)

In my Emacs session right now, I use `C-h f',
type `string' and `S-TAB', to (1) see all
that have `string' as substring and (2) see
that there are 459 of them.  And plain `TAB'
tells me there are 47 with `string' as prefix,
and matching `string-' instead of `string'
tells me there are 42 with that prefix (it
filters out candidates `string', `string<',
`string=', `string>', and `stringp').

In general, it's the completion _process_
that's important.  And that can serve several
goals.

Instead of focusing on just the goal of
choosing one candidate, consider the overall
process:

There's a set (domain) of possible candidates,
which you can you filter with your input.
You can do anything you want with a set of
candidates or any of its members, at any point
in the process.

> Also it doesn't quite work when the order is
> "reversed", e.g C-h f "string TAB multibyte"
> would not return the desired function
> because it has to be "multibyte TAB string".

For orderless matching I match the 2 patterns
separately.  With my UI that's `string S-SPC
multibyte' or `multibyte S-SPC string' - same
result: all matches, any order.

And of course all I really need to type are
some chars from those patterns. And I can
limit matches to candidates that start or
end with one of those patterns, not just
candidates that contain them.

Is what I'm saying limited to having a UI
that lets me do such non-vanilla stuff?  No.
With vanilla Emacs, out of the box, you can
use completion to _examine_ a set of matches.
That can tell you something.  It's not only
about choosing a candidate and acting on it
in only one way.  Completion is about sets.
___

https://www.emacswiki.org/emacs/Icicles_-_Nutshell_View#completionprocessandgoals