How to switch into completing-read-multiple from completing-read and run command for each candidate (like embark-act-all)?

I found that `completing-read` + `embark-act-all` rocks. For example, I can update all lsp-related package in straight.el by calling `straight-pull-package` and then type `lsp-` to get a list of completion candidates with lsp in the name. Then I call `embark-act-all` and pull all the selected packages. But it would be useful to be able to switch from an arbitrary `completing-read` minibuffer into `completing-read-multiple` via a key-press, collect multiple candidates (which don't necessarily have matching substrings), and then just run the original command for each of the selected candidates, e.g. via `embark-act-all`. This would be much more convenient than just running the command multiple times or what I sometimes do, mapping the function over the list in elisp (`M-: (seq-map #'<command> candidates)`) I could write my own function which calls `completing-read-multiple`, like `straight-pull-package-crm`, but it would be nice if something like that would be possible from any command. I'm asking because I thought something like that should already exist somewhere or be possible somehow with existing functionality in emacs/embark. Feel free to propose other solutions to my problem, as what I'm asking might be an [XY problem](https://en.wikipedia.org/wiki/XY_problem).

Not a direct answer to crm part, but I can think of two ways Embark supports acting on arbitrary sets of candidates. See [Working with sets of possible targets](https://github.com/oantolin/embark/#working-with-sets-of-possible-targets). You could use `embark-collect`, mark arbitrary candidates, then do `embark-act-all`. See [Quitting the minibuffer after an action](https://github.com/oantolin/embark/#quitting-the-minibuffer-after-an-action). You could `(setq embark-quit-after-action nil)` (or set it up per action, see docstring) and keep minibuffer open between actions.

embark-collect, marking and embark-act-all is a great solution!

Thanks a lot for the tips! Wasn't aware I could mark within the collect buffer. This is a nice way to go about it, I get my poor-guys package menu!

A bit off topic but never upgrade lsp-mode packages in the same session if they are already loaded. Just to be safe the best option is to delete the packages and install them after restarting emacs.

Thanks for the tip, didn't know it's that much of an issue. This means restarting the LSP workspaces/processes isn't enough? Usually I only do this deleting approach for all my packages after compiling a new Emacs version which is about weekly these days. And btw, thanks for your hard work on LSP-mode 🙏🙇‍♂️. And if that's your dog on your GitHub profile picture, he's super cute!

> This means restarting the LSP workspaces/processes isn't enough? That is enough. The issue is related to how package.el works and how that might break byte-compiling. Lets say you upgrade lsp-java and lsp-mode. You may end up with lsp-java bytecompiled against the lsp-mode that is already loaded and not the one that is actually required by lsp-java. We had a lot of issues related to that due to the extensive usage of macros in lsp-mode's code. > And if that's your dog on your GitHub profile picture, he's super cute! Thank you, it is she - Bela. :)