From: Eli Zaretskii <eliz@gnu.org>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: mardani29@yahoo.es, emacs-devel@gnu.org
Subject: Re: Q: Is there a built-in way to read multiple file names?
Date: Sat, 13 Jul 2024 17:28:55 +0300 [thread overview]
Message-ID: <86ikx9jrh4.fsf@gnu.org> (raw)
In-Reply-To: <87r0bxpecj.fsf@localhost> (message from Ihor Radchenko on Sat, 13 Jul 2024 14:15:56 +0000)
> 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?
next prev parent reply other threads:[~2024-07-13 14:28 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-07 7:22 Q: Is there a built-in way to read multiple file names? Ihor Radchenko
2024-07-07 13:26 ` Daniel Martín
2024-07-07 15:56 ` Ihor Radchenko
2024-07-07 16:03 ` Eli Zaretskii
2024-07-07 17:18 ` Ihor Radchenko
2024-07-07 17:38 ` Eli Zaretskii
2024-07-07 17:47 ` Ihor Radchenko
2024-07-07 17:56 ` Eli Zaretskii
2024-07-07 21:24 ` [External] : " Drew Adams
2024-07-13 13:57 ` Ihor Radchenko
2024-07-13 18:56 ` Drew Adams
2024-07-14 12:38 ` Ihor Radchenko
2024-07-14 17:23 ` Drew Adams
2024-07-15 18:56 ` Ihor Radchenko
2024-07-15 19:44 ` Drew Adams
2024-07-17 17:21 ` Ihor Radchenko
2024-07-17 19:49 ` Drew Adams
2024-07-13 13:43 ` Ihor Radchenko
2024-07-13 13:53 ` Eli Zaretskii
2024-07-13 14:15 ` Ihor Radchenko
2024-07-13 14:28 ` Eli Zaretskii [this message]
2024-07-14 12:16 ` Ihor Radchenko
2024-07-14 13:11 ` Eli Zaretskii
2024-07-15 18:52 ` Ihor Radchenko
2024-07-15 19:22 ` Eli Zaretskii
2024-07-15 19:52 ` Ihor Radchenko
2024-07-16 10:05 ` Eli Zaretskii
2024-07-23 11:13 ` Ihor Radchenko
2024-07-23 12:05 ` Eli Zaretskii
2024-07-23 16:30 ` Ihor Radchenko
2024-07-23 16:35 ` Eli Zaretskii
2024-07-23 16:40 ` Ihor Radchenko
2024-07-23 17:48 ` Eli Zaretskii
2024-07-23 16:02 ` Yuri Khan
2024-07-23 17:35 ` [External] : " Drew Adams
2024-07-16 5:09 ` Yuri Khan
2024-07-13 14:19 ` Thierry Volpiatto
2024-07-13 14:19 ` Ihor Radchenko
2024-07-08 12:00 ` Max Nikulin
2024-07-13 14:00 ` Ihor Radchenko
2024-07-14 9:00 ` Max Nikulin
2024-07-14 12:33 ` Ihor Radchenko
2024-07-15 12:12 ` Max Nikulin
-- strict thread matches above, loose matches on Subject: below --
2024-07-13 16:28 Rahguzar
2024-07-14 12:30 ` Ihor Radchenko
2024-07-14 20:29 ` Rahguzar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86ikx9jrh4.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=mardani29@yahoo.es \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).