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

[Thierry Volpiatto <thievol@posteo.net>]

Ihor Radchenko <yantar92@posteo.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> My concern about dired and similar is that it is not possible to exit
>>> them and go back to the original place as easily as C-g in the
>>> completion prompt. Interactive narrowing is also not as easy as in the
>>> completion.
>>
>> 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?
>
> (For context, I am interested in this question to extend M-x org-attach
> where I want to allow users select multiple files at once; or,
> similarly, to extend the email attachment prompt)

For your helm users you can already use something like this:

    (defvar helm-comp-read-use-marked)
    (if (bound-and-true-p helm-mode)
        (let ((helm-comp-read-use-marked t))
          (completing-read prompt candidates)) ; or read-file-name...
      (completing-read-multiple prompt candidates))

>>> IMHO, helm proves that completion framework can be used for very quick
>>> selection. It does it via:
>>> 
>>> 1. The notion of "current" candidate from the list that can be navigated
>>>    right from the minibuffer (like next/previous-completion in the
>>>    *completions*)
>>> 2. minibuffer command to mark/unmark candidates quickly
>>> 3. ability to retain marked candidates even the prompt input changes
>>> 
>>> I find it quick and convenient to use, despite being a completion
>>> framework.
>>> 
>>> 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?

-- 
Thierry