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

[Ihor Radchenko <yantar92@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> How to unmark after you go to a different directory?
>
> The same way you mark them?  Or maybe I don't understand what
> difficulties you have in mind.

Imagine that a user marks two files:
1. /home/user/1/2/3/4/5/file1
2. /home/user/5/4/3/2/1/file2

During step (2), dired will display <...>/5/4/3/2/1/ directory.

Now, imagine that file1 needs to be unmarked. To do it, the user will
have to go up all the way to /home/user and descent down to 1/2/3/4/5 -
very awkward. And even more awkward if the user does not remember the
full path for file1.

>> 'i' works poorly when the directories contain many files - you get way
>> too long list of files, potentially with duplicate names, that is a
>> nighmare to search through. Even with regexps.
>
> How is this different from a directory that has a lot of files to
> begin with?  Searching in an Emacs buffer is hardly a problem.  At the
> very least, it's way more convenient than searching a typical GUI
> file-selection dialog, at least IME.

The most important difference is that "i" may create duplicate file
names, which never happens when there is a single directory. Then,
searching cannot help much to narrow down to the desired file name.

Also, there will always be more files in multiple directories compared
to single directory (on average). So, users will have to search through
longer file lists.

>> >   . it is unusual, and so at least some users will be confused
>> 
>> Any new UI will be unusual.
>
> Selecting files from a Dired-like list is non unusual.  Both Emacs
> users and users who come from other GUI applications will feel right
> at home.

>> As since we cannot use dired as is (AFAIU),
>
> We can't? why not?

IMHO, dired as it does not provide a good way to _show_ which files are
selected without having to scroll through the whole file listing.

>> Also, I am not sure if it is that much unusual - I replicated my dired
>> look in the above. With
>> https://github.com/Fuco1/dired-hacks?tab=readme-ov-file#filter-groups,
>> it is how dired UI looks like. Example:
>
> You miss my point.  The unusual part is that the selected files are
> shown at the beginning of the buffer instead of being left in their
> original places with an indication that they were selected.

Sorry, I was not clear. I did not mean that marked files will be removed
from the main file listing. I meant that marked files will be displayed
on top _in addition_ to being marked in the normal listing. This is to
see an overview of all the selected files together, without having to
scroll through all the directory files (marked + unmarked).

>> > Because it is unusual and idiosyncratic.  By contrast, what I describe
>> > exists in many selection dialogs, and so will be familiar.
>> 
>> Yes, it is. Idiosyncratic for Emacs. Just like isearch.
>> I really see no reason to _not_ allow flexibility we already have in
>> Emacs and instead trying to mimic the limitations idiosyncatic to
>> Windows/Mac.
>
> What limitations are those?

No option to use custom `completion-styles'.

>> Maybe it is good enough? Especially since we may not want to shadow
>> existing single-letter bindings in dired.
>
> If that is the problem (but I don't see why, since most of those
> bindings are to dired-do-SOMETHING, which are not relevant for
> selecting files)

I mostly referred to "m" (mark) and "u" (unmark) bindings. They are relevant.

> ... , we can find a solution, like M-<letter> or
> something.

Could be an option, yes.

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