RE: [External] : Re: Add completion to compilation-read-command

[Drew Adams <drew.adams@oracle.com>]

1. I wasn't going to reply to the statements made 
about "completion" versus "narrowing", "selection", 
etc.  I think such a characterization isn't very 
useful, and it can be misleading.

Since I'm now replying (below), about Icicles, I'll
first say this about completion/narrowing/selection:

Emacs "completion" has always meant matching a (user)
pattern against some set of things, with the pattern
typically provided as text in the minibuffer or some 
other buffer.

IOW, completion is about _matching_, first & foremost.

Completion has also typically involved expanding or
replacing the pattern, based on the matches.  E.g.,
you type "forw", hit TAB, and your input pattern
might change to "forward-".

(In Icicles, such pattern expansion is optional - you
can toggle it on/off anytime during completion.)

The words "narrowing" and "selection" are less about
a mechanism, which "completion" speaks to, and more
about possible _uses_ of a completion mechanism.

I'm guessing that those who distinguished such things
from completion had a limited view of its possible
uses: limited to just obtaining a (single) completion
of a pattern - much as if the only use of `grep' were
to show all matches for a pattern and then let you
pick/access/use only one of them.

If that's how "completion" is viewed, then yes, 
"narrowing" and "selection" seem like very different 
things from completion.  That's not the way I view 
completion.

Of course, we use `grep' in many other ways, including
(1) seeing what all the matches are, and where they're
located (discovery etc.), and (2) piping `grep' output
to further `grep' patterns or other transformation
functions.

The uses of completion are really as general as those
of pattern matching.  Completion isn't at all limited
to obtaining a single completion.

The idea behind "narrowing" (it's really _progressive_
narrowing, since just a single act of completion
already narrows the original domain of candidates to
only those that match the initial pattern) is that
you can _chain together_ acts of completion/matching,
as you do when you pipe `grep' output through another
`grep' (or another kind of filter or a transformer),
etc. 

IOW, you can match one pattern, getting a set of
matches, and then filter those matches (as a new
domain of candidates) with another pattern, and so on.

This is different from just changing the input
pattern and recompleting, which just starts over again
with the original domain of candidates.

Of course, even such plain recompletion isn't limited
to a get-me-a-completion use case.  Like progressive
completion, it acts on a given _set_ of elements to
produce a new _set_.  Completion, in general, is an 
operation on sets: given a pattern and a set of
candidates, it returns a new set of candidates, which
match the pattern.

[ More generally, you can think "map"/"reduce": Besides
pattern-matching with filter functions, _transforming_
functions can be mapped across a set of candidates.
And an aggregation ("reduce") function can be applied
to a set of candidates together.  Dunno whether other
so-called "completion frameworks" offer this, but
Icicles does. ]

> > from this thread I learned that Icicles can be used 
> > to enhance completion similarly to how narrowing 
> > frameworks (like vertico) enhance narrowing.

It's the other way around.  Icicles did that for
decades before there were any other "narrowing
frameworks" or "completion frameworks".  And it's
not about "enhancing narrowing".  It's simply about 
ways of using (taking advantage of) completion
/ matching.

> I have never used it, because it is not available as 
> a package and it redefines built-in functions, but
> my understanding it that it is something similar.

2, I don't care that you've never used it, or why.
But for the record:

* It is a package.  It was on MELPA, till MELPA stopped
  pulling code from Emacs Wiki.  My other libraries 
  were also on MELPA.

* Icicles only redefines some predefined functions, and
  only while `icy-mode' is enabled (on).  When off, the
  original definitions are restored.

3. I'm no expert on the many "completion frameworks"
that've been added since Icicles.  But I have a hunch 
that none of them have something like the progressive 
completion of Icicles:

When you initiate a new completion / matching
/ filtering with a new pattern, you can do so in a
recursive minibuffer.  The previous set of matches
(completion candidates) then becomes the domain of
candidates for the current act of completing.

Using recursive minibuffers means, among other things, 
that you can return to any higher level and continue 
from there, branching down another trail of levels,
and so on.  In effect, there's a tree of possibilities.  
(You can also pop back to the top level directly 
anytime.)

> >> But for someone like me who doesn't use a
> >> selecting-narrowing framework like vertico, it
> >> suddenly means that SPC is rebound to
> >> `minibuffer-complete-word' and entering new
> >> commands becomes *a lot* more cumbersome.

4. On this I'll just say that I argued long ago for
Emacs to _not_ bind SPC in minibuffer keymaps to word 
completion.

To me, that's just an artifact / legacy left over from 
the fact that Emacs used completion pretty much only
for `M-x' and reading file names, and Emacs commands 
and file names rarely, if ever, contained SPC chars 
(esp. back then).

Completion being potentially usable for matching
against _any_ set of candidates, it makes sense in the 
vast majority of contexts (including potential) for
SPC to be self-inserting.

(Of course, in some contexts you might want using SPC 
in the minibuffer to do something besides adding a SPC 
char to your pattern to be matched.)

I argued the same for `?' and `C-j' (newline): by 
default they, like SPC, should self-insert in the 
minibuffer.  Eventually, after decades, SPC finally 
became self-inserting, but only for file-name
completion.

(I'd be willing to bet that other  "completion 
frameworks", like Icicles, let you insert such chars 
without using `C-q' etc.  I'm not betting on vanilla 
Emacs doing so anytime soon.)