Better alternative to completing-read-multiple

Better alternative to completing-read-multiple

[Ilya Chernyshov]

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

Re: Better alternative to completing-read-multiple

[Thierry Volpiatto]

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

RE: [External] : Better alternative to completing-read-multiple

[Drew Adams]

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

Re: Better alternative to completing-read-multiple

[Adam Porter]

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

RE: Better alternative to completing-read-multiple

[Иван С]

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.