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

[Ihor Radchenko <yantar92@posteo.net>]

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.

Moreover, in my experience using a similar command (implemented using
helm), completion is actually extremely useful:
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.
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)

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)?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>