bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Drew Adams]

> Incremental filtering while user is typing might cause too sluggish
> response, so I'm fine with the current non-incremental filtering.

It should be optional, and it should be controllable
by users.  Wrt the latter, the things that might
affect such performance could be controllable on the
fly (e.g. increment/decrement this or that, toggle
this or that on/off)

> BTW, what I still miss in package filtering is a key to match
> package descriptions (in addition to package names).  For example,
> Ubuntu package manager allows filtering by these fields:
> "Name", "Description and Name".

Icicles allows for optionally matching such things,
which are, in effect separate parts of the same
candidate (different colums of the same row of the
table, in this case).

For example, when you use `C-x C-f' you can optionally
match only the file name, only the file content, or
both.  You separate the two patterns (or more, for
other kinds of candidates) with the char(s) of
`icicle-list-join-string', which by default is just
"^G^J".

Users can customize this, and code can bind it.
Those odd control chars are used because such a
string is unlikely to be part of candidates to be
matched.  But you can change it to just " ", for
example.  And you can always enter this join-string
by hitting `C-M-j'.  The string just appears as a
newline in the minibuffer.  That is, the different
pattern parts start on new lines.

This "multi-completion" can be used with progressive
completion.  E.g., you can provide different patterns
to match as different steps of matching.  You need not
provide patterns to match the different parts in the
same, multi-part pattern.  As always with progressive
completion, `S-SPC' starts a new completion, with a
new pattern, against the candidates that result from 
matching previous patterns.