unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Ihor Radchenko <yantar92@posteo.net>
Cc: "mardani29@yahoo.es" <mardani29@yahoo.es>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: RE: [External] : Re: Q: Is there a built-in way to read multiple file names?
Date: Sun, 7 Jul 2024 21:24:00 +0000	[thread overview]
Message-ID: <SJ0PR10MB5488B6114B2B6D09AF870276F3D92@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <86ikxh13yc.fsf@gnu.org>

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




  reply	other threads:[~2024-07-07 21:24 UTC|newest]

Thread overview: 43+ 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               ` Drew Adams [this message]
2024-07-13 13:57                 ` [External] : " 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

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=SJ0PR10MB5488B6114B2B6D09AF870276F3D92@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=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).