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: Sun, 14 Jul 2024 12:16:53 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why do you need the minibuffer part "Choose files: CO"? why not simply
> > let users mark the selected files using Dired mark commands?
> > ...
> > How did "completion" enter the picture?  The original question was
> > about ways to select multiple files, which is much wider and more
> > general than just completing on file names.  When the user needs to
> > select a file, completion is just a means of saving them some typing.
> > That idea basically becomes irrelevant when users need to select
> > several files whose names might not have anything in common.  GUI
> > applications have solved this problem long ago, so why should Emacs
> > insist on inventing its own idiosyncratic solution?
> 
> In my use case, the user may not immediately know if she needs to attach
> a single file or multiple files. So, having two separate interfaces for
> single file vs. multiple files is awkward.

There's no need to use two interfaces.  use just one: the one that can
handle several files.  Selecting a single file from a list is known to
work and be natural for many years, including in Emacs.  We even have
a convention that if no files are marked, the current file is the
selected one.

> Moreover, in my experience using a similar command (implemented using
> helm), completion is actually extremely useful:

Resist that.  This will lead you astray.

> 1. It is much faster to jump to specific folder using completion
>    vs. using in-buffer navigation in dired. Especially when I am looking
>    for deeply nested folders.

Jumping to a folder doesn't need selection of more than one name, so I
don't see how it is relevant here.

> 2. It is not uncommon for me to attach files that have common
>    names. Having completion under the fingertips is better compared to
>    manually entering dired filters. (in dired, there is an extra key
>    sequence required)

Files that have common names are usually listed together, so I don't
think this problem is as serious as you describe it.  A useful feature
for selecting files is, when the user types a characters, to move
point the first file whose name begins with that character.  If we
implement that, you get the best of all worlds.

> I can totally see some people preferring dired buffer UI to select
> files, but then I do not see why the same people would not then prefer
> dired to select a single file as well. Is it something you think would
> be worth having (dired as _single_ file selection dialogue)?

Selecting a single file with Dired-like UI is IMO both possible and
natural, see above.