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

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

[Rahguzar]

> Sure, but I want the same thing to work for non-helm users.
> Preferably, without having to write helm-specific/ivy-specific/etc code.

If you want a mostly completing-read interface for this task, maybe the
function filechooser-read-file-names [1] from my GNU ELPA package
filechooser can help you. It uses a group-function to distinguish
selected files from the rest. It works pretty well with vertico but I
think should work with any UI which supports group-function well. It is
entangled with some details of the package so probably not directly
useful but I think adapting to an API similar to read-file-name is not
too hard and hopefully can help with something similar to serve Org's
needs.

There is also filechooser-dired for a dired based take.

[1] https://codeberg.org/rahguzar/filechooser/src/commit/62a9ef588331b06c818ea5db5a73e756f20fd13d/filechooser.el#L379

Rahguzar

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

[Ihor Radchenko]

Rahguzar <rahguzar@zohomail.eu> writes:

>> Sure, but I want the same thing to work for non-helm users.
>> Preferably, without having to write helm-specific/ivy-specific/etc code.
>
> If you want a mostly completing-read interface for this task, maybe the
> function filechooser-read-file-names [1] from my GNU ELPA package
> filechooser can help you. It uses a group-function to distinguish
> selected files from the rest. It works pretty well with vertico but I
> think should work with any UI which supports group-function well. It is
> entangled with some details of the package so probably not directly
> useful but I think adapting to an API similar to read-file-name is not
> too hard and hopefully can help with something similar to serve Org's
> needs.

Yes, it is quite similar to what I described

	  ------------- completions -----------------
	  [selected files group]
	  -rw-r--r--  1 yantar92 yantar92 35151 Jun 25 10:22 COPYING <MARKED>
	  [candidates group]
	  drwxr-xr-x  8 yantar92 yantar92  4096 Jul 13 16:04 .git
	  -rw-r--r--  1 yantar92 yantar92  1044 Jun 25 10:22 .gitignore
	  -rw-r--r--  1 yantar92 yantar92    95 Jun 25 10:22 .gitmodules
	  ------------------- minibuffer ------------------------
	  Choose files: git

I tried using 

(let ((filechooser-filters '(("All" always . t)))
      (filechooser-use-popup-frame nil))
  (filechooser-read-file-names "Files: "))

M-TAB selects file.
I did not find how to remove selected file.

The main problem is that it is not built-in, and I would like to get
something in the core to cater multi-file prompts.

A side note: The usual /old/path/to/file/~/restart/path does not work as expected.

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

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

[Rahguzar]

Hi Ihor,
Ihor Radchenko <yantar92@posteo.net> writes:

> Rahguzar <rahguzar@zohomail.eu> writes:
>
>>> Sure, but I want the same thing to work for non-helm users.
>>> Preferably, without having to write helm-specific/ivy-specific/etc code.
>>
>> If you want a mostly completing-read interface for this task, maybe the
>> function filechooser-read-file-names [1] from my GNU ELPA package
>> filechooser can help you. It uses a group-function to distinguish
>> selected files from the rest. It works pretty well with vertico but I
>> think should work with any UI which supports group-function well. It is
>> entangled with some details of the package so probably not directly
>> useful but I think adapting to an API similar to read-file-name is not
>> too hard and hopefully can help with something similar to serve Org's
>> needs.
>
> Yes, it is quite similar to what I described
>
> 	  ------------- completions -----------------
> 	  [selected files group]
> 	  -rw-r--r--  1 yantar92 yantar92 35151 Jun 25 10:22 COPYING <MARKED>
> 	  [candidates group]
> 	  drwxr-xr-x  8 yantar92 yantar92  4096 Jul 13 16:04 .git
> 	  -rw-r--r--  1 yantar92 yantar92  1044 Jun 25 10:22 .gitignore
> 	  -rw-r--r--  1 yantar92 yantar92    95 Jun 25 10:22 .gitmodules
> 	  ------------------- minibuffer ------------------------
> 	  Choose files: git
>
> I tried using 
>
> (let ((filechooser-filters '(("All" always . t)))
>       (filechooser-use-popup-frame nil))
>   (filechooser-read-file-names "Files: "))
>
> M-TAB selects file.
> I did not find how to remove selected file.

M-TAB on a selected file deselects it. It is basically a toggle.

> The main problem is that it is not built-in, and I would like to get
> something in the core to cater multi-file prompts.

I would like that too, and if something like that is in the core I will
change current implementation to depend on it. I am also happy to try to
upstream the code if that is considered desirable.

> A side note: The usual /old/path/to/file/~/restart/path does not work as expected.

Can you please describe how it doesn't work? It works for me with
vertico. I thought let binding minibuffer-completing-file-name was
enough to get rfn-eshadow to work.

Rahguzar

Alternative UI for reading multiple choices (was: Q: Is there a built-in way to read multiple file names?)

[Ihor Radchenko]

Rahguzar <rahguzar@zohomail.eu> writes:

>> The main problem is that it is not built-in, and I would like to get
>> something in the core to cater multi-file prompts.
>
> I would like that too, and if something like that is in the core I will
> change current implementation to depend on it. I am also happy to try to
> upstream the code if that is considered desirable.

Let's change the subject then.
Eli favours a completely different approach for selecting files in
particular, but improving `completing-read-multiple' is also worth
discussing:

- Built-in `completing-read-multiple' works fine using its idea with
  separators, but it is a pain to remove previously selected choices,
  especially long and complex ones.
   
- filechooser implements an alternative way to read multiple choices by
  showing them as additional completion group on top of the normal
  completions

- This is conceptually similar to icicles, except that the highlights in
  icicles may work not as good when the number of completion candidates
  is too large. I feel that visual indication in a separate group is
  better, except when all possible completions can fit within
  *completions* buffer window

- As we discussed with Drew, the problem with not having all the
  completions listed in the minibuffer (like in
  `completing-read-multiple') is that it does not get stored in the
  minibuffer history. And it would be nice to have access to such
  history for multiple choice prompt.

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

RE: [External] : Alternative UI for reading multiple choices (was: Q: Is there a built-in way to read multiple file names?)

[Drew Adams]

> - filechooser implements an alternative way to read multiple choices by
>   showing them as additional completion group on top of the normal
>   completions
> 
> - This is conceptually similar to icicles, except that the highlights in
>   icicles may work not as good when the number of completion candidates
>   is too large. I feel that visual indication in a separate group is
>   better, except when all possible completions can fit within
>   *completions* buffer window

The point, at that point, is to show the selected
candidates in the context of all candidates.

> - As we discussed with Drew, the problem with not having all the
>   completions listed in the minibuffer (like in
>   `completing-read-multiple') is that it does not get stored in the
>   minibuffer history. And it would be nice to have access to such
>   history for multiple choice prompt.

See my reply to your mail about that.

Retrieving a value from a history list is more
tedious than choosing a saved-candidates-set
variable from the set of such variables, using
completion.

That would be especially trie if your history
list contained also other stuff (e.g. values
returned from the minibuffer, as for normal
minibuffer histories).

ELPA package: filechooser (was: Q: Is there a built-in way to read multiple file names?)

[Ihor Radchenko]

Rahguzar <rahguzar@zohomail.eu> writes:

>> M-TAB selects file.
>> I did not find how to remove selected file.
>
> M-TAB on a selected file deselects it. It is basically a toggle.

Now got it. You are right. I did not realize that I need to narrow the
completions to the file I want to toggle. Just assumed that M-tab will
act on what is displayed on top in the completions buffer, which is the
first selected file - I was wrong.

>> A side note: The usual /old/path/to/file/~/restart/path does not work as expected.
>
> Can you please describe how it doesn't work? It works for me with
> vertico. I thought let binding minibuffer-completing-file-name was
> enough to get rfn-eshadow to work.

In short, I tried

1. Input ~/Git/emacs/src/xdisp.c
2. M-tab
3. ~/Git/emacs/src/~/

and the completion list is empty.

I recorded a short video demonstrating the problem.
https://0x0.st/XLFm.mkv

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

Re: ELPA package: filechooser

[Rahguzar]

Ihor Radchenko <yantar92@posteo.net> writes:

> Rahguzar <rahguzar@zohomail.eu> writes:
>
>>> M-TAB selects file.
>>> I did not find how to remove selected file.
>>
>> M-TAB on a selected file deselects it. It is basically a toggle.
>
> Now got it. You are right. I did not realize that I need to narrow the
> completions to the file I want to toggle. Just assumed that M-tab will
> act on what is displayed on top in the completions buffer, which is the
> first selected file - I was wrong.
>
>>> A side note: The usual /old/path/to/file/~/restart/path does not work as expected.
>>
>> Can you please describe how it doesn't work? It works for me with
>> vertico. I thought let binding minibuffer-completing-file-name was
>> enough to get rfn-eshadow to work.
>
> In short, I tried
>
> 1. Input ~/Git/emacs/src/xdisp.c
> 2. M-tab
> 3. ~/Git/emacs/src/~/
>
> and the completion list is empty.
>
> I recorded a short video demonstrating the problem.
> https://0x0.st/XLFm.mkv

You are right. The problem essentially boils down to this:

(let ((minibuffer-completing-file-name t))
 (completing-read "File: " #'completion-file-name-table))

The shadowing works as expected using vertico but not in the default
completion UI. I will try to figure out how exactly that is supposed to
be handled but I think the best place will be the
completion-file-name-table since otherwise every user of the table (or
the completion UI) needs to implement this behavior.

Rahguzar

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

[Ihor Radchenko]

Hello,

I am wondering if there is a built-in way to read one or more file names
in a single prompt.

AFAIK, `read-file-name' kind of allow this, if one uses wildcards, but
that approach is limited - not every combination of file names can be
expressed via wildcards.

I feel that such command should exist, but I cannot find it.

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

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

[Daniel Martín]

Ihor Radchenko <yantar92@posteo.net> writes:

> Hello,
>
> I am wondering if there is a built-in way to read one or more file names
> in a single prompt.
>
> AFAIK, `read-file-name' kind of allow this, if one uses wildcards, but
> that approach is limited - not every combination of file names can be
> expressed via wildcards.
>
> I feel that such command should exist, but I cannot find it.

You can read each filename by calling read-file-name in a loop, ending
with RET.  There is multi-isearch-read-files, but the prompt message is
coupled to isearch; it should be easy to generalize this function.

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

[Ihor Radchenko]

Daniel Martín <mardani29@yahoo.es> writes:

>> I feel that such command should exist, but I cannot find it.
>
> You can read each filename by calling read-file-name in a loop, ending
> with RET.  There is multi-isearch-read-files, but the prompt message is
> coupled to isearch; it should be easy to generalize this function.

That indeed works, but it is far from ideal:

1. It is not very extendable via helm/consult/ivy
2. When x-file-dialog is used, it is extremely annoying to run it in a loop

I am wondering if `read-file-name' could be extended to read multiple
file names at once.

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

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: emacs-devel@gnu.org
> Date: Sun, 07 Jul 2024 15:56:45 +0000
> 
> Daniel Martín <mardani29@yahoo.es> writes:
> 
> >> I feel that such command should exist, but I cannot find it.
> >
> > You can read each filename by calling read-file-name in a loop, ending
> > with RET.  There is multi-isearch-read-files, but the prompt message is
> > coupled to isearch; it should be easy to generalize this function.
> 
> That indeed works, but it is far from ideal:
> 
> 1. It is not very extendable via helm/consult/ivy
> 2. When x-file-dialog is used, it is extremely annoying to run it in a loop
> 
> I am wondering if `read-file-name' could be extended to read multiple
> file names at once.

I think you are generalizing the wrong UI.  A good UI for specifying
several file names is not reading them one after the other, it is
marking the files you want to operate on, and then clicking GO.  Like
in Ibuffer, for example.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> I am wondering if `read-file-name' could be extended to read multiple
>> file names at once.
>
> I think you are generalizing the wrong UI.  A good UI for specifying
> several file names is not reading them one after the other, it is
> marking the files you want to operate on, and then clicking GO.  Like
> in Ibuffer, for example.

I 100% agree.
That's what helm provides, say, for `completing-read-multiple'.
But for `read-file-name' specifically, there is no way to extend the
built-in completion.

I wish that *completions* buffer allowed selecting multiple candidates
at once when using `completing-read-multiple' or similar commands.

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

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: mardani29@yahoo.es, emacs-devel@gnu.org
> Date: Sun, 07 Jul 2024 17:18:33 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I am wondering if `read-file-name' could be extended to read multiple
> >> file names at once.
> >
> > I think you are generalizing the wrong UI.  A good UI for specifying
> > several file names is not reading them one after the other, it is
> > marking the files you want to operate on, and then clicking GO.  Like
> > in Ibuffer, for example.
> 
> I 100% agree.
> That's what helm provides, say, for `completing-read-multiple'.
> But for `read-file-name' specifically, there is no way to extend the
> built-in completion.

We have Ibuffer and Dired (and other similar features), which
functions that return lists of marked entities.  That is what needs
to be used for multiple selections, not some loop over read-file-name
and its ilk.

> I wish that *completions* buffer allowed selecting multiple candidates
> at once when using `completing-read-multiple' or similar commands.

I think completion is the wrong framework for this purpose, because
the user might want to select files/buffers/whatever whose names don't
share anything in common.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> > I think you are generalizing the wrong UI.  A good UI for specifying
>> > several file names is not reading them one after the other, it is
>> > marking the files you want to operate on, and then clicking GO.  Like
>> > in Ibuffer, for example.
>> 
>> I 100% agree.
>> That's what helm provides, say, for `completing-read-multiple'.
>> But for `read-file-name' specifically, there is no way to extend the
>> built-in completion.
>
> We have Ibuffer and Dired (and other similar features), which
> functions that return lists of marked entities.  That is what needs
> to be used for multiple selections, not some loop over read-file-name
> and its ilk.

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 wish that *completions* buffer allowed selecting multiple candidates
>> at once when using `completing-read-multiple' or similar commands.
>
> I think completion is the wrong framework for this purpose, because
> the user might want to select files/buffers/whatever whose names don't
> share anything in common.

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.

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

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: mardani29@yahoo.es, emacs-devel@gnu.org
> Date: Sun, 07 Jul 2024 17:47:56 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We have Ibuffer and Dired (and other similar features), which
> > functions that return lists of marked entities.  That is what needs
> > to be used for multiple selections, not some loop over read-file-name
> > and its ilk.
> 
> 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.)

> >> I wish that *completions* buffer allowed selecting multiple candidates
> >> at once when using `completing-read-multiple' or similar commands.
> >
> > I think completion is the wrong framework for this purpose, because
> > the user might want to select files/buffers/whatever whose names don't
> > share anything in common.
> 
> 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.

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

[Ihor Radchenko]

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)

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

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

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

[Eli Zaretskii]

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

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

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

Will something like

------------- dired-completion-mode -----------------
[candidates]
-rw-r--r--  1 yantar92 yantar92   936 Jun 25 10:22 CONTRIBUTE.org
-rw-r--r--  1 yantar92 yantar92 35151 Jun 25 10:22 COPYING
------------------- minibuffer ------------------------
Choose files: CO

work?

Basically, instead of the completion buffer, there is dired-derived
buffer narrowed according to the minibuffer input.

Then, users can mark files by switching to "dired-completion-mode" and
using the usual dired mark commands, including bulk marks.

------------- dired-completion-mode -----------------
[selected files]
-rw-r--r--  1 yantar92 yantar92 35151 Jun 25 10:22 COPYING <MARKED>
[candidates]
-rw-r--r--  1 yantar92 yantar92   936 Jun 25 10:22 CONTRIBUTE.org
------------------- minibuffer ------------------------
Choose files: CO

Later, users can go back to minibuffer and change the input, narrowing
to a potentially different set of files:

------------- dired-completion-mode -----------------
[selected files]
-rw-r--r--  1 yantar92 yantar92 35151 Jun 25 10:22 COPYING <MARKED>
[candidates]
drwxr-xr-x  8 yantar92 yantar92  4096 Jul 13 16:04 .git
-rw-r--r--  1 yantar92 yantar92  1044 Jun 25 10:22 .gitignore
-rw-r--r--  1 yantar92 yantar92    95 Jun 25 10:22 .gitmodules
------------------- minibuffer ------------------------
Choose files: git

They can then mark the new files as needed

------------- dired-completion-mode -----------------
[selected files]
-rw-r--r--  1 yantar92 yantar92 35151 Jun 25 10:22 COPYING <MARKED>
drwxr-xr-x  8 yantar92 yantar92  4096 Jul 13 16:04 .git <MARKED>
-rw-r--r--  1 yantar92 yantar92    95 Jun 25 10:22 .gitmodules <MARKED>
[candidates]
-rw-r--r--  1 yantar92 yantar92  1044 Jun 25 10:22 .gitignore
------------------- minibuffer ------------------------
Choose files: git

... or unmark, by using the unmark commands in the same buffer on
"selected files".

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

This sounds a bit strange, but I think that this line of the discussion
is deviating from my central question of multi-file selection.
How exactly the minibuffer input is matched against the files (be it
just a file name/path or also attributes/contents/major mode/what not)
is not my concern. Let's focus on selecting multiple files via
completion.

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

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: mardani29@yahoo.es, emacs-devel@gnu.org
> Date: Sat, 13 Jul 2024 14:15:56 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> 
> Will something like
> 
> ------------- dired-completion-mode -----------------
> [candidates]
> -rw-r--r--  1 yantar92 yantar92   936 Jun 25 10:22 CONTRIBUTE.org
> -rw-r--r--  1 yantar92 yantar92 35151 Jun 25 10:22 COPYING
> ------------------- minibuffer ------------------------
> Choose files: CO
> 
> work?

Why do you need the minibuffer part "Choose files: CO"? why not simply
let users mark the selected files using Dired mark commands?

> Later, users can go back to minibuffer and change the input, narrowing
> to a potentially different set of files:
> 
> ------------- dired-completion-mode -----------------
> [selected files]
> -rw-r--r--  1 yantar92 yantar92 35151 Jun 25 10:22 COPYING <MARKED>
> [candidates]
> drwxr-xr-x  8 yantar92 yantar92  4096 Jul 13 16:04 .git
> -rw-r--r--  1 yantar92 yantar92  1044 Jun 25 10:22 .gitignore
> -rw-r--r--  1 yantar92 yantar92    95 Jun 25 10:22 .gitmodules
> ------------------- minibuffer ------------------------
> Choose files: git

I think the minibuffer part is over-engineering it.  Dired has all the
functionality you need, including the ability to go to different
directories etc.  There's no need to invoke completion-like UIs, which
basically all assume the file names have common beginnings.  This
assumption is a limitation when selecting multiple files.

> Let's focus on selecting multiple files via completion.

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?

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

[Ihor Radchenko]

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>

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

[Eli Zaretskii]

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

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

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

I am not convinced that Dired UI is better, but I can see how dired UI
can be a good choice for some people. Let's discuss what should be
changed in dired to adapt it to multi-file selection.

I am trying to simulate some use-cases when users need to select
multiple files using dired:

1. Single file is trivial
2. Multiple files in the same folder are also trivial - use mark
   commands
3. What does not seem to be trivial is selecting multiple files residing
   in different folders. What do you think should be done to dired to
   get this?

   I am thinking about something similar to my previous ideas - having a
   separate section in dired buffer that lists marked files.

   --------------  dired-select -------------------
  [ Selected files ]
* -rw-r--r-- 1 yantar92  1.2M Jul  6 15:31 xdisp.c (from Git/emacs/src/)
* -rw-r--r-- 1 yantar92 2.5K May  3 15:24 local.mk (from Git/org-mode)
* -rw-r--r-- 1 yantar92 3.8K Jul 13 18:16 Makefile (from Git/org-mode)
  [ Dir ]
  /home/yantar92/Git/org-mode:
  drwxr-xr-x 3 yantar92 4.0K Jul 15 09:48 doc
  drwxr-xr-x 5 yantar92 4.0K Jul 15 09:06 etc
  drwxr-xr-x 2 yantar92  20K Jul 15 16:30 lisp
  drwxr-xr-x 2 yantar92 4.0K Jul 13 18:16 mk
  drwxr-xr-x 2 yantar92 4.0K Jun 12  2022 paches
  drwxr-xr-x 5 yantar92 4.0K Jul 15 10:45 testing
  -rw-r--r-- 1 yantar92  936 Jun 25 10:22 CONTRIBUTE.org
  -rw-r--r-- 1 yantar92 1.9K Jun 25 10:22 README.org
  -rw-r--r-- 1 yantar92  35K Jun 25 10:22 COPYING
* -rw-r--r-- 1 yantar92 2.5K May  3 15:24 local.mk
* -rw-r--r-- 1 yantar92 3.8K Jul 13 18:16 Makefile

  My only concern is what to do when the folder contains many files and
  the first section listing the marked files may not be visible when
  scrolling the buffer.

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

Why only to file that _begins_ with a character? Why not also moving to
a file that have specific work in its name? regexp? I feel that we are
coming back to the idea of completing read...

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

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: mardani29@yahoo.es, emacs-devel@gnu.org
> Date: Mon, 15 Jul 2024 18:52:00 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> 3. What does not seem to be trivial is selecting multiple files residing
>    in different folders. What do you think should be done to dired to
>    get this?

Why do you need to change anything?  It should be possible to mark
some files, then go to a different directory and mark some more files,
etc.  When the user eventually types "C-c C-c", the list of all the
selected files in all the directories is returned to the caller.

An alternative could be for the user to insert another directory into
the buffer, like 'i' in Dired does.

>    I am thinking about something similar to my previous ideas - having a
>    separate section in dired buffer that lists marked files.
> 
>    --------------  dired-select -------------------
>   [ Selected files ]
> * -rw-r--r-- 1 yantar92  1.2M Jul  6 15:31 xdisp.c (from Git/emacs/src/)
> * -rw-r--r-- 1 yantar92 2.5K May  3 15:24 local.mk (from Git/org-mode)
> * -rw-r--r-- 1 yantar92 3.8K Jul 13 18:16 Makefile (from Git/org-mode)
>   [ Dir ]
>   /home/yantar92/Git/org-mode:
>   drwxr-xr-x 3 yantar92 4.0K Jul 15 09:48 doc
>   drwxr-xr-x 5 yantar92 4.0K Jul 15 09:06 etc
>   drwxr-xr-x 2 yantar92  20K Jul 15 16:30 lisp
>   drwxr-xr-x 2 yantar92 4.0K Jul 13 18:16 mk
>   drwxr-xr-x 2 yantar92 4.0K Jun 12  2022 paches
>   drwxr-xr-x 5 yantar92 4.0K Jul 15 10:45 testing
>   -rw-r--r-- 1 yantar92  936 Jun 25 10:22 CONTRIBUTE.org
>   -rw-r--r-- 1 yantar92 1.9K Jun 25 10:22 README.org
>   -rw-r--r-- 1 yantar92  35K Jun 25 10:22 COPYING
> * -rw-r--r-- 1 yantar92 2.5K May  3 15:24 local.mk
> * -rw-r--r-- 1 yantar92 3.8K Jul 13 18:16 Makefile

This has two disadvantages:

  . if there are many files, moving too far down will scroll the
    selected files out of view
  . it is unusual, and so at least some users will be confused

> > 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.
> 
> Why only to file that _begins_ with a character? Why not also moving to
> a file that have specific work in its name? regexp?

Because it is unusual and idiosyncratic.  By contrast, what I describe
exists in many selection dialogs, and so will be familiar.

But if you want to have selection based on regexps, then Dired has the
"% m REGEXP" command.  So this, too, is already available.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> 3. What does not seem to be trivial is selecting multiple files residing
>>    in different folders. What do you think should be done to dired to
>>    get this?
>
> Why do you need to change anything?  It should be possible to mark
> some files, then go to a different directory and mark some more files,
> etc.  When the user eventually types "C-c C-c", the list of all the
> selected files in all the directories is returned to the caller.

How to unmark after you go to a different directory?

> An alternative could be for the user to insert another directory into
> the buffer, like 'i' in Dired does.

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

>>    --------------  dired-select -------------------
>>   [ Selected files ]
>> * -rw-r--r-- 1 yantar92  1.2M Jul  6 15:31 xdisp.c (from Git/emacs/src/)
>>   [ Dir ]
>>   /home/yantar92/Git/org-mode:
> ...
>
> This has two disadvantages:
>
>   . if there are many files, moving too far down will scroll the
>     selected files out of view

Sure. That's literally my concern as well. That's why I suggested to use
completion-based interface rather than dired-based. With completions
window, there is usually no need to scroll - typing in minibuffer is a
lot more efficient to narrow down to the desired file.

As an alternative, maybe we can list the selected files in the minibuffer?

>   . it is unusual, and so at least some users will be confused

Any new UI will be unusual. As since we cannot use dired as is (AFAIU),
introducing something new is simply inevitable.

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:

  /home/yantar92/Git/org-mode:
  [ Dirs ]
  drwxr-xr-x 3 yantar92 4.0K Jul 15 09:48 doc
  drwxr-xr-x 5 yantar92 4.0K Jul 15 09:06 etc
  drwxr-xr-x 2 yantar92  20K Jul 15 16:30 lisp
  drwxr-xr-x 2 yantar92 4.0K Jul 13 18:16 mk
  drwxr-xr-x 2 yantar92 4.0K Jun 12  2022 paches
  drwxr-xr-x 5 yantar92 4.0K Jul 15 10:45 testing
  [ Documents ]
  -rw-r--r-- 1 yantar92  936 Jun 25 10:22 CONTRIBUTE.org
  -rw-r--r-- 1 yantar92 1.9K Jun 25 10:22 README.org
  [ Default ]
  -rw-r--r-- 1 yantar92  35K Jun 25 10:22 COPYING
  -rw-r--r-- 1 yantar92 2.5K May  3 15:24 local.mk
  -rw-r--r-- 1 yantar92 3.8K Jul 13 18:16 Makefile

>> > 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.
>> 
>> Why only to file that _begins_ with a character? Why not also moving to
>> a file that have specific work in its name? regexp?
>
> 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.

> But if you want to have selection based on regexps, then Dired has the
> "% m REGEXP" command.  So this, too, is already available.

I was talking about jumping to regexp match.
In any case, isearch should be available, including searching by regexp.
Maybe it is good enough? Especially since we may not want to shadow
existing single-letter bindings in dired.

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

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: mardani29@yahoo.es, emacs-devel@gnu.org
> Date: Mon, 15 Jul 2024 19:52:26 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 3. What does not seem to be trivial is selecting multiple files residing
> >>    in different folders. What do you think should be done to dired to
> >>    get this?
> >
> > Why do you need to change anything?  It should be possible to mark
> > some files, then go to a different directory and mark some more files,
> > etc.  When the user eventually types "C-c C-c", the list of all the
> > selected files in all the directories is returned to the caller.
> 
> 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.

> > An alternative could be for the user to insert another directory into
> > the buffer, like 'i' in Dired does.
> 
> '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.

> >   . if there are many files, moving too far down will scroll the
> >     selected files out of view
> 
> Sure. That's literally my concern as well. That's why I suggested to use
> completion-based interface rather than dired-based. With completions
> window, there is usually no need to scroll - typing in minibuffer is a
> lot more efficient to narrow down to the desired file.
> 
> As an alternative, maybe we can list the selected files in the minibuffer?

The mini-window is ill-suited for showing long lists, so I'd recommend
against that.

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

> introducing something new is simply inevitable.
> 
> 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.

> >> Why only to file that _begins_ with a character? Why not also moving to
> >> a file that have specific work in its name? regexp?
> >
> > 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?

> > But if you want to have selection based on regexps, then Dired has the
> > "% m REGEXP" command.  So this, too, is already available.
> 
> I was talking about jumping to regexp match.
> In any case, isearch should be available, including searching by regexp.

Exactly.

> 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), we can find a solution, like M-<letter> or
something.

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

[Ihor Radchenko]

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>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: mardani29@yahoo.es, emacs-devel@gnu.org
> Date: Tue, 23 Jul 2024 11:13:07 +0000
> 
> 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.

It isn't any more awkward than the way forward, from
/home/user/1/2/3/4/5/file1 to /home/user/5/4/3/2/1/file2.

If you want to help such use case, my suggestion is to show the list
of selected items in a separate window.

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

If we insist on digging out problems, however rare and improbable, we
will never do anything at all.  I don't see how the minor issues you
mention justify an idiosyncratic solution specific to Emacs.  Have we
learned nothing from our long history?  Idiosyncratic solutions could
be justified when there was no "prior art" because Emacs was a
pioneering application, but this is not that case, far from it.

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

I cannot disagree more.  You are rejecting a good solution with which
Emacs users, both veteran and newbies, are familiar enough, for no
good reason.

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

If you want to show a list of selected files, show them in a separate
window, but leave the original Dired-style list of the files intact.

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

First, that could be added without changing the UI and UX.  And
second, how did we get to completion again? this is about selection of
multiple files, not about completion.

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

Those commands could be bound to non-character keys, at least as an
option.

Once again, we should first make the overall design decisions, and
only after that talk about minor details like key bindings.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> If you want to show a list of selected files, show them in a separate
> window, but leave the original Dired-style list of the files intact.

That's an option. I am wondering what kind of window configuration
should be used to show the two windows.

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

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: mardani29@yahoo.es, emacs-devel@gnu.org
> Date: Tue, 23 Jul 2024 16:30:33 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If you want to show a list of selected files, show them in a separate
> > window, but leave the original Dired-style list of the files intact.
> 
> That's an option. I am wondering what kind of window configuration
> should be used to show the two windows.

Probably something at user's control.  There's no way to know how
small or large the user screen could be, and how they like their
windows.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> That's an option. I am wondering what kind of window configuration
>> should be used to show the two windows.
>
> Probably something at user's control.  There's no way to know how
> small or large the user screen could be, and how they like their
> windows.

Sure. But it is not clear how users will control it.
We always have `display-buffer-alist', but it is more suited for
individual windows, while we need to coordinate two windows together in
this scenario.

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

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: mardani29@yahoo.es, emacs-devel@gnu.org
> Date: Tue, 23 Jul 2024 16:40:05 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> That's an option. I am wondering what kind of window configuration
> >> should be used to show the two windows.
> >
> > Probably something at user's control.  There's no way to know how
> > small or large the user screen could be, and how they like their
> > windows.
> 
> Sure. But it is not clear how users will control it.

Via a user option, I guess, how else?

> We always have `display-buffer-alist', but it is more suited for
> individual windows, while we need to coordinate two windows together in
> this scenario.

I see no reason to use such a heavy hammer in this case.

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

[Yuri Khan]

On Tue, 23 Jul 2024 at 18:12, Ihor Radchenko <yantar92@posteo.net> wrote:

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

It seems to me what you want is a shopping cart UI for files.

Use cases:

1. When in a Dired buffer, I want to be able to add one or more files
to the cart.
2. When in a Dired buffer containing one or more files that are in the
cart, I want to see them as marked.
3. When in a Dired buffer containing one or more files that are in the
cart, I want to be able to remove some of them from the cart.
4. At any time, I want to be able to see the list of files in the cart.
5. When in the cart, I want to be able to remove some or all of its files.
6. When in the cart, I want to be able to execute a command that
accepts a set of files.

Stretch goal:

7. I want to be able to have multiple carts, one of them designated as
“current” for purposes of cases 1–3.
8. When in the cart, I want to see the total number and/or size and/or
disk usage of its files.

A cart could be a separate buffer containing full file names, one per
line, with embedded newlines suitably escaped.

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

[Yuri Khan]

On Tue, 16 Jul 2024 at 01:51, Ihor Radchenko <yantar92@posteo.net> wrote:

> Why only to file that _begins_ with a character? Why not also moving to
> a file that have specific wor[d] in its name? regexp?

Prior art: In file managers descending from Norton Commander, there is
usually a way to start typing to get incremental prefix search over
file names; if you enter a * at the search prompt, it becomes
substring/glob search.

In my experience, wanting to use the full power of regular expressions
has been rare; the extension of glob mini-language with character sets
like [aoeui] or [0-9] proved to be handy at times.

(Anyway, isearch solves both needs; type-to-search-by-prefix only
makes it more convenient for the most common case.)

(Somewhat off-topic but related: In those same NC-descending file
managers, when you start typing, the default behavior is for typed
characters to go into the shell prompt. I have missed this
type-to-shell feature in Dired on many occasions.)

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

[Thierry Volpiatto]

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

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

[Ihor Radchenko]

Thierry Volpiatto <thievol@posteo.net> writes:

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

Sure, but I want the same thing to work for non-helm users.
Preferably, without having to write helm-specific/ivy-specific/etc code.

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

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

[Max Nikulin]

On 07/07/2024 23:03, Eli Zaretskii wrote:
>> From: Ihor Radchenko Date: Sun, 07 Jul 2024 15:56:45 +0000
>>
>> I am wondering if `read-file-name' could be extended to read multiple
>> file names at once.
> 
> I think you are generalizing the wrong UI.  A good UI for specifying
> several file names is not reading them one after the other, it is
> marking the files you want to operate on, and then clicking GO.  Like
> in Ibuffer, for example.

Marking items is convenient in some cases, but I like that 
bash-completion or built-in readline path completion in shell prompt 
allow me to *type* multiple file names. However it better than strictly 
"one after another" since it is possible to move earlier typed text and 
to edit it.

Ihor, have you considered custom keymap to add current text to a list 
variable? However editing earlier added entries may be tricky.

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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> Marking items is convenient in some cases, but I like that 
> bash-completion or built-in readline path completion in shell prompt 
> allow me to *type* multiple file names. However it better than strictly 
> "one after another" since it is possible to move earlier typed text and 
> to edit it.

Do you mean wildcards?

> Ihor, have you considered custom keymap to add current text to a list 
> variable? However editing earlier added entries may be tricky.

This is conceptually similar to `completing-read-multiple', AFAIU:

Prompt: exact-file-name,file-with-wildcard.*,another-file

Is my understanding correct?

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

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

[Max Nikulin]

On 13/07/2024 21:00, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> Marking items is convenient in some cases, but I like that
>> bash-completion or built-in readline path completion in shell prompt
>> allow me to *type* multiple file names. However it better than strictly
>> "one after another" since it is possible to move earlier typed text and
>> to edit it.
> 
> Do you mean wildcards?

Wildcards are convenient as well, but primary I had in mind multiple 
arguments

     tar cvfz f.tar.gz one/two.txt three/four/five.jpg six/seven.org

I would prefer to avoid rambling through directories and marking files 
when I approximately know location of files. I find it convenient to 
type and hit TAB (or C-/ in some cases) to confirm that a file exists.

>> Ihor, have you considered custom keymap to add current text to a list
>> variable? However editing earlier added entries may be tricky.
> 
> This is conceptually similar to `completing-read-multiple', AFAIU:
> 
> Prompt: exact-file-name,file-with-wildcard.*,another-file
> 
> Is my understanding correct?

If `completing-read-multiple' may be combined with file name completion 
and escaping of separators then yes.

At first I though that it might be easier to bind to key sequences some 
functions that add/remove current text to/from an externally maintained 
list (perhaps displayed in another buffer) while single item is 
presented in the minibuffer. However is should be a pain when users 
configure their preferred completion frameworks.

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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> Do you mean wildcards?
>
> Wildcards are convenient as well, but primary I had in mind multiple 
> arguments
>
>      tar cvfz f.tar.gz one/two.txt three/four/five.jpg six/seven.org
>
> I would prefer to avoid rambling through directories and marking files 
> when I approximately know location of files. I find it convenient to 
> type and hit TAB (or C-/ in some cases) to confirm that a file exists.

Sorry, but I do not understand what you are describing.
Do you mean that you type partial completion, hit TAB, and get _all_ the
matching candidates completed, separated by spaces?

> At first I though that it might be easier to bind to key sequences some 
> functions that add/remove current text to/from an externally maintained 
> list (perhaps displayed in another buffer) while single item is 
> presented in the minibuffer. However is should be a pain when users 
> configure their preferred completion frameworks.

I think that icicles does exactly this. So does
filechooser-read-file-names that Rahguzar shared.

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

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

[Max Nikulin]

On 14/07/2024 19:33, Ihor Radchenko wrote:
> Max Nikulin writes:
>>       tar cvfz f.tar.gz one/two.txt three/four/five.jpg six/seven.org
>>
>> I would prefer to avoid rambling through directories and marking files
>> when I approximately know location of files. I find it convenient to
>> type and hit TAB (or C-/ in some cases) to confirm that a file exists.
> 
> Sorry, but I do not understand what you are describing.
> Do you mean that you type partial completion, hit TAB, and get _all_ the
> matching candidates completed, separated by spaces?

Usually it is something like

     tar cvfz f.tar.gz on<TAB>tw<TAB> th<TAB>fo<TAB>f<TAB> s<TAB>se<TAB>

to get arguments in the command above. In most cases I prefer this way, 
not marking each file and directory view may be distracting (at least 
til <TAB><TAB> to get list of completions). It is basic completion. 
Rarely I use M-* insert-completions readline function.

>> At first I though that it might be easier to bind to key sequences some
>> functions that add/remove current text to/from an externally maintained
>> list (perhaps displayed in another buffer) while single item is
>> presented in the minibuffer. However is should be a pain when users
>> configure their preferred completion frameworks.
> 
> I think that icicles does exactly this. So does
> filechooser-read-file-names that Rahguzar shared.

I do not mind. The question is how much efforts are necessary for 
minimal variant without external dependencies.