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

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: [External] : Re: Q: Is there a built-in way to read multiple file names?

[Drew Adams]

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


The Subject line says "built-in".  But it
seems the thread has moved on to talk about
ways that aren't built-in.

In that context, I'll mention Icicles wrt
some things that have been brought up.
(This has been available since 2006.)
____

1. Wrt "marking" files for some action:

Icicles calls this "saving" instead of
"marking" a completion candidate.

The list of file names you chose ("save")
is the value of a variable (by default,
`icicle-saved-completion-candidates').
You can also save them to a file.

. The `<insert>' key saves the "current"
  candidate (e.g., during cycling).
. In *Completions*, `M-S-mouse-2' on a
  candidate saves it.
  Alternatively, `mouse-1' before a
  candidate, then `mouse-3' twice after
  it, saves it.
. `C-M->' saves all candidates.
. `C-M-)' saves the candidates in the
  active region in *Completions*.
. `M-S-mouse-3' in *Completions* saves
  all candidates, or those in the region
  if active.
. `C-M-<' retrieves a set of saved
  candidates at any time, replacing the
  current set of candidates.
. There are also keys to _add to_ a set
  of saved candidates.


2. You can match file content, in addition
to, or instead of, file name.


3. Wrt choosing files according to file
attributes:

One of the variables that controls matching
and filtering is `icicle-file-predicate'.
You can use that to filter candidates that
have certain attribute values.  E.g., this
predicate limits candidates to files whose
size is at least 5000 bytes:

(lambda (f)
  (> (file-attribute-size
       (file-attributes f)) 
     5000)))


4. Wrt choosing (e.g. "marking") a set of
files using different criteria, matching
different name or content patterns, with
different attributes, locations, etc.:

You can use one set of completion criteria
and "save" some candidates based on that,
then change to a different set of criteria
and "save" some more.  You can accumulate
criteria, narrowing a set of matches by
adding another criterion (e.g., additional
name pattern).

You can save sets to different variables.
You can recombine multiple saved sets.
(And then filter that combination, save
from it, etc.)


5. You can mark file names in Dired and
create, or add to, "saved" sets of names
for subsequent use in file-completion
commands (retrieve sets as candidates).
______

You don't NEED to "mark" (save) a set
of file-name candidates to act on them,
of course.  You do that when it makes
sense - in particular, when you're likely
to want to reuse such a set later.
______

Saving and retrieving completion-candidate
sets (file names are one kind of candidate)
is described here:

Quick description:

https://www.emacswiki.org/emacs/Icicles_-_Nutshell_View#ChooseBeforeYouAct

More extensive description:

https://www.emacswiki.org/emacs/Icicles_-_Candidate_Sets

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]

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: [External] : Re: Q: Is there a built-in way to read multiple file names?

[Ihor Radchenko]

Drew Adams <drew.adams@oracle.com> writes:

> The Subject line says "built-in".  But it
> seems the thread has moved on to talk about
> ways that aren't built-in.

I was hoping that there is something built-in, but since there is none,
I'd like to see how Emacs devs envision the possible UIs.

> In that context, I'll mention Icicles wrt
> some things that have been brought up.
> (This has been available since 2006.)
> ____
>
> 1. Wrt "marking" files for some action:
>
> Icicles calls this "saving" instead of
> "marking" a completion candidate.
> ...

This is similar to what I had in mind, yes.
Even better - you can maintain multiple "marked sets".

Visual highlighting of the "marked"/"saved" candidates is also a very
good idea.

As an alternative, there is also `completing-read-multiple' approach
with inserting the selected candidates into the minibuffer. Although, it
is inferior to what you described and to helm's mark system because it
is very hard to toggle selection when things are inserted into the minibuffer.

> 2. You can match file content, in addition
> to, or instead of, file name.

I'd prefer to limit this discussion to multi-file selection. More
sophisticated match criteria may better be discussed in a different
thread to not complicate things.

> 5. You can mark file names in Dired and
> create, or add to, "saved" sets of names
> for subsequent use in file-completion
> commands (retrieve sets as candidates).

This is also an interesting idea, thanks!
I think that `dired-dwim-target-directory' is doing something similar,
but only for default directory.
Something like (imaginary) `dired-dwim-marked-files' could be similarly
useful in the context of multi-file selection.

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

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

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

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

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

dog-wagging systems

[chad]

[-- Attachment #1.1: Type: text/plain, Size: 635 bytes --]

Excerpting from another thread:

On Sat, Jul 13, 2024 at 9:30 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > Let's focus on selecting multiple files via completion.
>
> How did "completion" enter the picture?
>

Catching up on this conversation, it strikes me that emacs seems especially
prone to creating Borg-like systems that start focused, gain adherents,
then expand to include all nearby territory, especially UI territory. I'm
thinking of gnus, company/ivy/helm, and org (as well as some MIT-specific
systems from my youth); I'm sure there are more.

Is this just another corollary of Greenspun's Tenth?

~Chad

[-- Attachment #1.2: Type: text/html, Size: 1030 bytes --]

[-- Attachment #2: Type: text/plain, Size: 92 bytes --]

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Drew Adams]

> > 1. Wrt "marking" files for some action:
> >
> > Icicles calls this "saving" instead of
> > "marking" a completion candidate.
> > ...
> 
> This is similar to what I had in mind, yes.
> Even better - you can maintain multiple "marked sets".

Yes.  And "maintaining" and creating can
involve using different set operations
(interactively, during completion).

https://www.emacswiki.org/emacs/Icicles_-_Candidate_Sets#SetOperations

By default, candidates are saved to, and
retrieved from, variable
`icicle-saved-completion-candidates'.  You
can use other variables (a prefix arg to
a saving or retrieving command prompts you
for the var).

Why is it important to be able to have
multiple saved sets of candidates?  You
can go to the trouble of creating a saved
set of candidates just once (however you
want, whether with Icicles interactively -
matching, filtering, selecting - or by
editing a list, or by program), then reuse
that set any time later.

You can also save a candidate set to a
file, persisting it so you can retrieve it
in other Emacs sessions.

> Visual highlighting of the "marked"/"saved"
> candidates is also a very good idea.

It's essential, especially if you want to
interactively UNmark (for saving) some of
currently marked candidates at some point.

> > 5. You can mark file names in Dired and
> > create, or add to, "saved" sets of names
> > for subsequent use in file-completion
> > commands (retrieve sets as candidates).
> 
> This is also an interesting idea, thanks!

Works also for other Dired-like buffers,
such as those from commands such as
`find-name-dired' or `find-grep-dired'.
You can use such a command as a starting
point, mark some of the found files, then
save those marked as a candidate set.

> I think that `dired-dwim-target-directory'
> is doing something similar

That just gives you a different directory
for use with commands in Dired.  It has
nothing to do with marking/selecting files
for use later as completion candidates.

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]

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?

[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: [External] : Re: Q: Is there a built-in way to read multiple file names?

[Ihor Radchenko]

Drew Adams <drew.adams@oracle.com> writes:

>> This is similar to what I had in mind, yes.
>> Even better - you can maintain multiple "marked sets".
>
> Yes.  And "maintaining" and creating can
> involve using different set operations
> (interactively, during completion).
>
> https://www.emacswiki.org/emacs/Icicles_-_Candidate_Sets#SetOperations
>
> By default, candidates are saved to, and
> retrieved from, variable
> `icicle-saved-completion-candidates'.  You
> can use other variables (a prefix arg to
> a saving or retrieving command prompts you
> for the var).
>
> Why is it important to be able to have
> multiple saved sets of candidates?  You
> can go to the trouble of creating a saved
> set of candidates just once (however you
> want, whether with Icicles interactively -
> matching, filtering, selecting - or by
> editing a list, or by program), then reuse
> that set any time later.
>
> You can also save a candidate set to a
> file, persisting it so you can retrieve it
> in other Emacs sessions.

This sounds overengineered. What you describe is an equivalent of
`completing-read' HISTORY argument.

-- 
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: [External] : Re: Q: Is there a built-in way to read multiple file names?

[Drew Adams]

> This sounds overengineered. What you describe is an equivalent of
> `completing-read' HISTORY argument.

No, there's really no relation to any HISTORY
argument.  Minibuffer history args record only
minibuffer input that you've _entered_ (`RET').

(And yes, you can persist minibuffer history
variables.  They're still unrelated.)

1. `C-x C-f' followed by a pattern to match
one or more files.  Then `TAB' to complete
the pattern. 

2. Mark any of those candidates, or all at
once, to `icicle-saved-completion-candidates'
(or to any other var - that's the default).

3. Reminder: you're still reading file
names with completion.  You haven't yet
hit `RET' or `C-g'.  You're just typing a
pattern, seeing what matches, and maybe
selecting some candidates.

Change your minibuffer pattern - maybe
one for a completely different location
(directory or file system).  Hit `TAB'
again, to see the matches for that new
pattern.

4. Repeat step #2, but this time saving
by _adding_ the matching file names to
the same saved candidate set.

5. Repeat steps #3 and #2 as much as you
like. Each time you're matching different
sets of files - anywhere - using different
patterns.

6. Hit `C-g' to cancel reading file names.

You just interactively explored files
all over the place, picking some to act
on, adding their names to a list stored
in a variable.  You never visiting any of
the files.

You can now (or later) use `C-x C-f' again
and retrieve the saved set of candidates
to visit them all.  Or use any other
command that reads file names and acts on
those files.

Or you can visit them all instead of
hitting `C-g' (step 6): just retrieve all
the saved names and hit `RET'.
___

Even if you match just one file name each
time, the point's the same: quickly pick
up file names from anywhere, matching
different patterns.

Adding files to an existing saved set is
as quick as adding them to an empty set.
The former is `C->', the latter's `C-M->'.

Or for a persistent set, the former is
`C-u C->' and the latter's `C-u C-M->'.

https://www.emacswiki.org/emacs/Icicles_-_Persistent_Completions#SavingInCacheFiles

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.

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: [External] : Re: Q: Is there a built-in way to read multiple file names?

[Ihor Radchenko]

Drew Adams <drew.adams@oracle.com> writes:

>> This sounds overengineered. What you describe is an equivalent of
>> `completing-read' HISTORY argument.
>
> No, there's really no relation to any HISTORY
> argument.  Minibuffer history args record only
> minibuffer input that you've _entered_ (`RET').

Sure. But if multi-selection is incorporated into standard APIs, history
may also hold the information about selected elements, in addition to
minibuffer input. I do not see a reason to keep it as a completely
separate structure.

> 1. `C-x C-f' followed by a pattern...
>
> 2. Mark any of those candidates...
> ...
> Change your minibuffer pattern...
>
> 4. Repeat...

Yes, makes sense.

> 6. Hit `C-g' to cancel reading file names.

Why not <RET>? (I guess simply because icicles builds on top of
completion, instead of extending it. I am aiming to extend the
completion/selection UI)

-- 
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: [External] : Re: Q: Is there a built-in way to read multiple file names?

[Drew Adams]

> >> This sounds overengineered. What you describe is an
> >> equivalent of `completing-read' HISTORY argument.
> >
> > No, there's really no relation to any HISTORY
> > argument.  Minibuffer history args record only
> > minibuffer input that you've _entered_ (`RET').
> 
> Sure. But if multi-selection is incorporated into standard APIs, history
> may also hold the information about selected elements, in addition to
> minibuffer input. I do not see a reason to keep it as a completely
> separate structure.

Sorry, not clear to me.  Define "history of selected
elements".

By "selected elements" I assume you mean something
like what we've been discussing: designating/marking
some file names (or more generally any kind of
completion candidates) for use as a group at some
time, particularly at some time other than during
the current act of completing patterns.

Saving such a set of candidates somewhere (register,
variable, file etc.) is what I've been talking about.
You say that that's overkill, and that some notion
of history gives you the same capability.  I don't
see that, and I don't see that you've described it.

For minibuffer input there really is a history
determined by the act of hitting RET at some point.

Likewise, for Icicles selection ("saving") of
candidates.

If your proposed marking is similar then what's the
difference?  The "history" that records the set of
marked candidates needs to be saved somewhere.

Certainly you could save multiple sets of candidates
to the same variable (or register or file etc.).
Perhaps that's what you're suggesting.  E.g., a var
that holds a list of candidate sets instead of just
one.

I didn't do that for Icicles because I didn't see
a need (use case) for it.  Typically, when you want
to retrieve a candidate set later (i.e., to use it
as the current set of "matching completions"), you
don't want to have to cycle through some list of
sets to get the one you want.

You can think of this like saving a minibuffer
pattern, then retrieving it later to use it again,
to get the same set of matching candidates.

But no single pattern would suffice, in general.
You might have (1) used several different patterns,
and possibly (2) used some in sequence (progressive
completion, aka progressive filtering), and (3)
selected (aka marked) among matches during #1 or #2
just some that you actually want to include ("save").

> > 1. `C-x C-f' followed by a pattern...
> > 2. Mark any of those candidates...
> > ...
> > Change your minibuffer pattern...
> > 4. Repeat...
> 
> Yes, makes sense.
> 
> > 6. Hit `C-g' to cancel reading file names.
> 
> Why not <RET>? (I guess simply because icicles builds on top of
> completion, instead of extending it. I am aiming to extend the
> completion/selection UI)

You _can_ certainly hit RET at any time, accepting
the text currently in the minibuffer (which adds
that to the current minibuffer history list).

Until Icicles, that was the _only_ point of a
completion function such as `completing-read': to
get a value that the user chooses.

The point in step #6 (`C-g') was that you don't
_have_ to enter anything - you don't _have_ to end
the call to `completing-read' or whatever at that
point.  You can completion not for a return value
but for performing different actions on candidates.
(One such action is to select some for later use
as a candidate set.)

IOW, you can use completion _not just_ to provide
a value for `read-file-name' or `completing-read',
but also for other purposes.  Those purposes
include (1) discovery - explore the domain of
candidates, (2) see info/help about candidates,
(3) accumulate a selection of candidates, and
(4...) lots more.

This is about #3.  And you can gather candidates
across any number of different acts of completion
(still within the same `completing-read' etc.
call, using any number of different minibuffer
patterns.

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?

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

[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: [External] : Re: Q: Is there a built-in way to read multiple file names?

[Ihor Radchenko]

Drew Adams <drew.adams@oracle.com> writes:

>> Sure. But if multi-selection is incorporated into standard APIs, history
>> may also hold the information about selected elements, in addition to
>> minibuffer input. I do not see a reason to keep it as a completely
>> separate structure.
>
> Sorry, not clear to me.  Define "history of selected
> elements".
>
> By "selected elements" I assume you mean something
> like what we've been discussing: designating/marking
> some file names (or more generally any kind of
> completion candidates) for use as a group at some
> time, particularly at some time other than during
> the current act of completing patterns.

Not really.
In this thread, I am not discussing multi-selection in the completing
read commands that are not asking for multiple answers.
What I am interested in is extension of the UI of
`completing-read-multiple' - when Elisp code _asks_ for one or more
inputs.

I understand that icicles is doing more than this, but I am not
interested in icicles as is. Just in the ideas it introduces as they might
be used in the more conventional Emacs workflows (read-multiple in
particular)

-- 
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] : Re: Q: Is there a built-in way to read multiple file names?

[Drew Adams]

> >> Sure. But if multi-selection is incorporated into standard APIs,
> history
> >> may also hold the information about selected elements, in addition to
> >> minibuffer input. I do not see a reason to keep it as a completely
> >> separate structure.
> >
> > Sorry, not clear to me.  Define "history of selected
> > elements".

Still not defined?

> > By "selected elements" I assume you mean something
> > like what we've been discussing: designating/marking
> > some file names (or more generally any kind of
> > completion candidates) for use as a group at some
> > time, particularly at some time other than during
> > the current act of completing patterns.
> 
> Not really.
> In this thread, I am not discussing multi-selection in the completing
> read commands that are not asking for multiple answers.
> What I am interested in is extension of the UI of
> `completing-read-multiple' - when Elisp code _asks_ for one or more
> inputs.
> 
> I understand that icicles is doing more than this, but I am not
> interested in icicles as is. Just in the ideas it introduces as they might
> be used in the more conventional Emacs workflows (read-multiple in
> particular)

You snipped my main message, about history,
which was to say that accessing such info via
history (e.g. M-p, M-n, M-r, M-s) is more
cumbersome than _completing_ against a set of
choices, which allows not only cycling (M-p/n)
and regexp matching (M-r/s), but additional
ways to match/access candidates directly.

Anyway, it's your enhancement project.  Just
adding this comment about access via history.
___

Of course, history access can also be enhanced,
including to give access using completion.

https://www.emacswiki.org/emacs/Icicles_-_History_Enhancements

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?

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

[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: [External] : Re: Q: Is there a built-in way to read multiple file names?

[Drew Adams]

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

Sorry, I just scanned your mail quickly.

If you use Dired+ then you can do any of these:

 . Omit the unmarked files, showing only the marked
   ones, with command `diredp-omit-marked'.
   This just uses `dired-do-kill-lines'.

 . Dired just the marked files, with command
   `diredp-marked'.
   This just calls `dired' with a list of the marked
   files.

 . Use command `diredp-list-marked' to list them in
   a separate buffer, optionally with info about the
   files.

The definitions are tiny, if you don't want all of
dired+.el.

HTH.

https://www.emacswiki.org/emacs/download/dired%2b.el

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.