RE: [External] : Re: Q: Is there a built-in way to read multiple file names?

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

> >> This sounds overengineered. What you describe is an
> >> equivalent of `completing-read' HISTORY argument.
> >
> > No, there's really no relation to any HISTORY
> > argument.  Minibuffer history args record only
> > minibuffer input that you've _entered_ (`RET').
> 
> Sure. But if multi-selection is incorporated into standard APIs, history
> may also hold the information about selected elements, in addition to
> minibuffer input. I do not see a reason to keep it as a completely
> separate structure.

Sorry, not clear to me.  Define "history of selected
elements".

By "selected elements" I assume you mean something
like what we've been discussing: designating/marking
some file names (or more generally any kind of
completion candidates) for use as a group at some
time, particularly at some time other than during
the current act of completing patterns.

Saving such a set of candidates somewhere (register,
variable, file etc.) is what I've been talking about.
You say that that's overkill, and that some notion
of history gives you the same capability.  I don't
see that, and I don't see that you've described it.

For minibuffer input there really is a history
determined by the act of hitting RET at some point.

Likewise, for Icicles selection ("saving") of
candidates.

If your proposed marking is similar then what's the
difference?  The "history" that records the set of
marked candidates needs to be saved somewhere.

Certainly you could save multiple sets of candidates
to the same variable (or register or file etc.).
Perhaps that's what you're suggesting.  E.g., a var
that holds a list of candidate sets instead of just
one.

I didn't do that for Icicles because I didn't see
a need (use case) for it.  Typically, when you want
to retrieve a candidate set later (i.e., to use it
as the current set of "matching completions"), you
don't want to have to cycle through some list of
sets to get the one you want.

You can think of this like saving a minibuffer
pattern, then retrieving it later to use it again,
to get the same set of matching candidates.

But no single pattern would suffice, in general.
You might have (1) used several different patterns,
and possibly (2) used some in sequence (progressive
completion, aka progressive filtering), and (3)
selected (aka marked) among matches during #1 or #2
just some that you actually want to include ("save").

> > 1. `C-x C-f' followed by a pattern...
> > 2. Mark any of those candidates...
> > ...
> > Change your minibuffer pattern...
> > 4. Repeat...
> 
> Yes, makes sense.
> 
> > 6. Hit `C-g' to cancel reading file names.
> 
> Why not <RET>? (I guess simply because icicles builds on top of
> completion, instead of extending it. I am aiming to extend the
> completion/selection UI)

You _can_ certainly hit RET at any time, accepting
the text currently in the minibuffer (which adds
that to the current minibuffer history list).

Until Icicles, that was the _only_ point of a
completion function such as `completing-read': to
get a value that the user chooses.

The point in step #6 (`C-g') was that you don't
_have_ to enter anything - you don't _have_ to end
the call to `completing-read' or whatever at that
point.  You can completion not for a return value
but for performing different actions on candidates.
(One such action is to select some for later use
as a candidate set.)

IOW, you can use completion _not just_ to provide
a value for `read-file-name' or `completing-read',
but also for other purposes.  Those purposes
include (1) discovery - explore the domain of
candidates, (2) see info/help about candidates,
(3) accumulate a selection of candidates, and
(4...) lots more.

This is about #3.  And you can gather candidates
across any number of different acts of completion
(still within the same `completing-read' etc.
call, using any number of different minibuffer
patterns.