* Better alternative to completing-read-multiple
@ 2024-04-19 21:18 Ilya Chernyshov
2024-04-20 6:16 ` Thierry Volpiatto
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Ilya Chernyshov @ 2024-04-19 21:18 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]
Hello
In completing-read-multiple, the resulting list of chosen strings is made
by splitting the input string with crm-separator regular expression variable.
This approach is not suitable for a list of candidates where a candidate
string might contain a character that is currently treated as a
separator. Imagine a situation where you read a list of Org headings
from user. In an Org heading you can have any character including the
default separator ",". Changing the value of crm-separator locally is
not a solution here.
A much better solution could be a completion command where a chosen
candidate is appended to a list (displayed in the prompt) when a user
presses RET and then returned when a user presses something like
C-RET. Already chosen candidates could be erased via C-<backspace>
This functionality definitely could be helpful at least in org, org-ql packages
(for completion over org headings).
I am not an Elisp expert, but here's some drafts. If you are interested,
please comment.
Test the function:
(ic-completing-read-multiple "Prompt: " '("first" "second" "third"))
[-- Attachment #2: ic-read-multiple.el --]
[-- Type: application/emacs-lisp, Size: 2160 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Better alternative to completing-read-multiple
2024-04-19 21:18 Better alternative to completing-read-multiple Ilya Chernyshov
@ 2024-04-20 6:16 ` Thierry Volpiatto
2024-04-20 15:22 ` [External] : " Drew Adams
2024-04-20 17:20 ` Adam Porter
2 siblings, 0 replies; 5+ messages in thread
From: Thierry Volpiatto @ 2024-04-20 6:16 UTC (permalink / raw)
To: Ilya Chernyshov; +Cc: emacs-devel
Ilya Chernyshov <ichernyshovvv@gmail.com> writes:
> Hello
>
> In completing-read-multiple, the resulting list of chosen strings is made
> by splitting the input string with crm-separator regular expression variable.
>
> This approach is not suitable for a list of candidates where a candidate
> string might contain a character that is currently treated as a
> separator. Imagine a situation where you read a list of Org headings
> from user. In an Org heading you can have any character including the
> default separator ",". Changing the value of crm-separator locally is
> not a solution here.
>
> A much better solution could be a completion command where a chosen
> candidate is appended to a list (displayed in the prompt) when a user
> presses RET and then returned when a user presses something like
> C-RET. Already chosen candidates could be erased via C-<backspace>
You can provide this feature to Helm users:
--8<---------------cut here---------------start------------->8---
(defvar helm-comp-read-use-marked)
(let ((lst '(a b c d e)))
(if (boundp 'helm-comp-read-use-marked)
(let ((helm-comp-read-use-marked t))
(completing-read "test: " lst))
(completing-read-multiple "test: " lst)))
--8<---------------cut here---------------end--------------->8---
The completing-read will return a list of marked candidates, if Helm is
not available fallback to CRM.
> This functionality definitely could be helpful at least in org, org-ql packages
> (for completion over org headings).
>
> I am not an Elisp expert, but here's some drafts. If you are interested,
> please comment.
>
> Test the function:
>
> (ic-completing-read-multiple "Prompt: " '("first" "second" "third"))
>
>
--
Thierry
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [External] : Better alternative to completing-read-multiple
2024-04-19 21:18 Better alternative to completing-read-multiple Ilya Chernyshov
2024-04-20 6:16 ` Thierry Volpiatto
@ 2024-04-20 15:22 ` Drew Adams
2024-04-20 17:20 ` Adam Porter
2 siblings, 0 replies; 5+ messages in thread
From: Drew Adams @ 2024-04-20 15:22 UTC (permalink / raw)
To: Ilya Chernyshov, emacs-devel@gnu.org
> A much better solution could be a completion command where a chosen
> candidate is appended to a list (displayed in the prompt) when a user
> presses RET and then returned when a user presses something like
> C-RET. Already chosen candidates could be erased via C-<backspace>
FWIW, Icicles does something similar
(since 2005): "multi-completion".
____
https://www.emacswiki.org/emacs/Icicles_-_Multi-Completions#multi-completion
____
Multi-completion differs from
`completing-read-multiple' in several ways.
In particular, it completes each input
pattern against a _different_ set of
candidates. `completing-read-multiple'
completes all input patterns against the
same set of candidates in the completion
domain.
E.g., Icicles' version of `C-x C-f' can
match both file names (first component)
and file content (second component).
In effect, completion candidates are
themselves multipart. But a command can
optionally hide any parts from display
in buffer `*Completions*'. E.g.,
`C-x C-f' hides file-content matches.
____
The key used to prompt for another input
pattern, to match the next completion
component, is, by default, `C-M-j'.
That inserts the chars that are the current
value of variable `icicle-list-join-string'.
Its default value is the string "^G^J", i.e.
Control-G followed by Control-J.
That odd value is the default because:
* It's unlikely to be part of a completion
candidate.
* A newline (C-j) visually separates the
multiple component input patterns.
* It's not difficult to type, using either
`C-M-j' or `C-q C-g C-j'.
Icicles displays the separator string as
just a newline (`C-j'). (The default
value of `icicle-list-join-string' has
property `(display "")' on its first char.)
A user can of course use a different
separator string. Likewise, different
commands can use different separator
strings - e.g., if input patterns are
expected to be short and simple, then
just a space or a comma can make sense.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Better alternative to completing-read-multiple
2024-04-19 21:18 Better alternative to completing-read-multiple Ilya Chernyshov
2024-04-20 6:16 ` Thierry Volpiatto
2024-04-20 15:22 ` [External] : " Drew Adams
@ 2024-04-20 17:20 ` Adam Porter
2 siblings, 0 replies; 5+ messages in thread
From: Adam Porter @ 2024-04-20 17:20 UTC (permalink / raw)
To: ichernyshovvv; +Cc: emacs-devel
Hi Ilya,
I like this. The code seems simple, and it looks very useful. CRM with
its separator regexp has always seemed awkward, and this seems to solve
the problem well.
I'd recommend looping in relevant fellow developers like Daniel Mendler
and Omar Antolín Camarena, as their feedback from working on packages
like Consult, Vertico, Orderless, and Embark should be helpful.
--Adam
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Better alternative to completing-read-multiple
@ 2024-04-21 22:16 Иван С
0 siblings, 0 replies; 5+ messages in thread
From: Иван С @ 2024-04-21 22:16 UTC (permalink / raw)
To: ichernyshovvv; +Cc: 87o7a59hks.fsf, emacs-devel
There is nothing wrong with completing-read-multiple. completing-read
is for reading *strings*, and completing-read-multiple is a wrapper
that allows you to narrow the completion to *the portion of the
string* after the specified regex.
I don't think your solution is general enough to justify its adoption right now.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-04-21 22:16 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-19 21:18 Better alternative to completing-read-multiple Ilya Chernyshov
2024-04-20 6:16 ` Thierry Volpiatto
2024-04-20 15:22 ` [External] : " Drew Adams
2024-04-20 17:20 ` Adam Porter
-- strict thread matches above, loose matches on Subject: below --
2024-04-21 22:16 Иван С
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).