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

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: mardani29@yahoo.es, emacs-devel@gnu.org
> Date: Sat, 13 Jul 2024 13:43:53 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I didn't mean Dired as use it for browsing a directory.  I meant a UI
> > for selecting multiple files that reuses Dired, and lets users exit it
> > with "C-c C-c" or somesuch.
> >
> > IOW, my intent was to point out the features to generalize and extend
> > in order to have what you want.  (For buffers, I think Ibuffer already
> > offers an almost complete solution.)
> 
> May you please explain in more details how you envision such multi-file
> selection interface?

Basically, present a Dired-like list of files and let the users mark
the files they want to select.  Many GUI programs show file-selection
dialogs, which allow selection of more than one file, and that is what
I had in mind.

> >> I also do not see why the same cannot be done based on the basis of
> >> completion-list-mode.
> >
> > The display parts might be suitable for selection, but the entire
> > completion machinery behind this makes absolutely no sense for the
> > purpose of selection based on attributes that are not names or
> > collection of strings.
> 
> Is it? AFAIK, packages like consult allow searching by metadata. Isn't
> custom COLLECTION function not suitable?

Of course, one can make the COLLECTION function do whatever one wants,
including coffee, love, and whatnot.  But how in the world could the
result be called "completion" if it doesn't complete anything??