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

[Drew Adams]

> >> 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".

Still not defined?

> > 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.
> 
> Not really.
> In this thread, I am not discussing multi-selection in the completing
> read commands that are not asking for multiple answers.
> What I am interested in is extension of the UI of
> `completing-read-multiple' - when Elisp code _asks_ for one or more
> inputs.
> 
> I understand that icicles is doing more than this, but I am not
> interested in icicles as is. Just in the ideas it introduces as they might
> be used in the more conventional Emacs workflows (read-multiple in
> particular)

You snipped my main message, about history,
which was to say that accessing such info via
history (e.g. M-p, M-n, M-r, M-s) is more
cumbersome than _completing_ against a set of
choices, which allows not only cycling (M-p/n)
and regexp matching (M-r/s), but additional
ways to match/access candidates directly.

Anyway, it's your enhancement project.  Just
adding this comment about access via history.
___

Of course, history access can also be enhanced,
including to give access using completion.

https://www.emacswiki.org/emacs/Icicles_-_History_Enhancements