modularizing citar--select-multiple

[hermanhel]

Hi, loved the citar--select-multiple UI! It is the best completion UI I've ever seen in emacs, and I wonder if you guys are interested in making it a seperate package?

I'm currently using a hacky snippet

(defun hermanhel-strings-to-hash (strings)
  "Convert a list of STRINGS to a hash table with the strings as keys."
  (let ((hash (make-hash-table :test 'equal)))
    (dolist (str strings)
      (puthash str t hash))
    hash))
(setq candidates (hermanhel-strings-to-hash '("item 1" "item ,2" "item 3")))

(citar--select-multiple "References: " candidates) 

which enables selecting and returning selected items(and avoiding the CRM-seperator "," breaks item with "," in it caveat). TAB and ENT on selected item will result in error but otherwise it does the job, so I imagine it won't be too much of a hassle?

[bdarcus]

Hi, loved the citar--select-multiple UI! It is the best completion UI I've ever seen in emacs, and I wonder if you guys are interested in making it a seperate package?

Doubtful, for a few reasons:

1. It's a custom re-implementation of the consult-completing-read-multiple that minad removed because of some limitations that were hard (impossible?) to resolve. See consult-completing-read-multiple does not handle completion-file-name-table correctly minad/consult#567. Not sure if that is true here as well.
2. I personally think we need to resolve when selecting multiple references, keep the current filter #783 for it be ideal.
3. More broadly, I'm not sure if I have the time/interest myself in spinning off another package, given the maintenance burdens. Here we can just focus on what we need.

But I didn't write this code anyway ;-)

cc @aikrahguzar @roshanshariff

EDIT: for consistency.

[aikrahguzar]

I think such a more general citar--select-multiple is possible but it is non-trivial. The only place where it can be freely adopted by other packages is Emacs core and that will require even more effort.

@hermanhel if you want to experiment with this here are my thoughts when I did something similar for filechooser:

1. The cleanest way I can see of obtaining something general is to write a transformer which takes a completion table and outputs another completion table. Morally this completions table just add selected candidates to those returned by the original completion table. It also modifies the metadata to differentiate selected and non-selected candidates.
2. This completion table can then be passed to completing-read in a loop. This should take care of vertico like UIs and should work for simple collections.
3. However doing this with complete generality is some amount of work since collections with many different forms can be passed to completing-read. If the form of collection is known in advance (as for citar and filechooser) things are easy but doing this generally will require a thorough reading of completion sections in emacs and elisp manuals.
4. This general functions will likely need to do give callers ability to do some stuff in between the iterations of the loop. It is not clear to me what is the best way to expose that.
5. Completion boundaries are difficult to tackle in generality. This is the problem discussed in consult-completing-read-multiple does not handle completion-file-name-table correctly minad/consult#567 . This is a problem that can be solved on a case by case basis but it is not clear to me a general solution exists.
6. Another thing to think about is how such a function will interact with default completion. The semantics of try-completion for this completion-table transformer will be quite difficult to figure out exactly.