unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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: Sun, 07 Jul 2024 20:56:11 +0300	[thread overview]
Message-ID: <86ikxh13yc.fsf@gnu.org> (raw)
In-Reply-To: <874j916qlv.fsf@localhost> (message from Ihor Radchenko on Sun, 07 Jul 2024 17:47:56 +0000)

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



  reply	other threads:[~2024-07-07 17:56 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 [this message]
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
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=86ikxh13yc.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).