CRM and initial-input question

[bdarcus]

Question, @minad:

In vertico (and selectrum), if one specifies initial-input in a CRM interface, the initial-input only applies to the first selection.

Use cases for bibtex-actions:

1. I want to read a collection of keys at-point and pass them to vertico/selectrum to narrow to those three, but select two of them to run the command on.
2. same thing to pre-filter items that have associated PDF flies, or notes

In each case, if one tab-selects a candidate, the initial-input is removed, and the result is the full candidate list.

Another one of those pain points for me in CRM.

Is this something that can/should be fixed in existing CRM UIs, or does it seem like the long term solution is what we've previously discussed at radian-software/selectrum#489, and to allow things like "select all" for a list of such narrowed candidates?

[minad]

Maybe I misunderstood the question, but this works for me in both Vertico and Selectrum:

(completing-read-multiple "Select: " '("first" "second" "third") nil 'require-match "first,second,")

[minad]

Regarding the completing-read-multiple pain points - currently I don't have plans to "enhance" crm in Vertico. Vertico treats crm as a simple programmable completion table. Selectrum is more intrusive here, since it replaces the existing completion table. For Vertico, Crm is not an abstract API - it is a concrete implementation of a programmable completion table. From how it is constructed internally in Emacs, it is actually not meant to be replaced (except via advices).

You could experiment with writing your own crm-like programmable completion table. Take a look at the source of completing-read-multiple and crm--collection-fn. Maybe you can construct a better completion table which fits your bibtex purposes better. This requires more digging into how these tables are implemented internally. There is one caveat though - programmable (dynamic) completion tables do not work properly in Selectrum. They only work in fully compliant UIs like default completion, Icomplete and Vertico.

From what I know, there are these types of completion tables:

1. Static tables, for example plain lists. Work everywhere.
2. Dynamic/programmable tables. Work in fully compliant UIs like default completion, Icomplete or Vertico. Examples: File completion, crm, Info-goto-node.
3. Broken dynamic tables. Org mode has a few of those (e.g., org-set-tags-command). These tables work only with default completion as long as you do not modify the completion-styles. The tables follow the completion API in a too strongly restricted sense and make assumptions about the completion-style, e.g., the basic completion style must be used.
4. Consult asynchronous tables - these tables are essentially static, but request the UI to perform an update. For this reason they work everywhere, as long as Consult knows how to do the UI refresh.

[hmelman]

That last part would be good in a README.

[bdarcus]

Maybe I misunderstood the question, but this works for me in both Vertico and Selectrum:

(completing-read-multiple "Select: " '("first" "second" "third") nil 'require-match "first,second,")

Hi @minad - conceptually, this is what we're doing:

(completing-read-multiple "Select: " '("a one" "a two" "a three" "b four") nil 'require-match "a")

So initially, the first three candidates display.

If I select first and tab, all then display.

So the simple question is why doesn't the initial value get added after the first selection?

But maybe, as you suggest in the subsequent comments, this isn't the best tool for the job. Seems I might want to look into consult asynchronous tables?

[minad]

Okay, I understand. This is not how CRM works, but you could write your own CRM-like completion table which adds the initial value every time. Consult async tables are not a solution for the problem here.

[bdarcus]

Got it. Thank you!

[bdarcus]

There is one caveat though - programmable (dynamic) completion tables do not work properly in Selectrum.

Just one additional question actually, on this, since it's important: do you see this situation as likely to be resolved? I know there's a PR related to dynamic tables, but not sure how it fits, and I know it's been sitting for awhile.

[minad]

Just one additional question actually, on this, since it's important: do you see this situation as likely to be resolved? I know there's a PR related to dynamic tables, but not sure how it fits, and I know it's been sitting for awhile.

I hope so. It is good to have alternatives and it is good to have different independent packages maintained by different people. With that PR and maybe a few other changes, the issues can be fixed (dynamic tables, completion boundaries). There is another issue on the Selectrum tracker, where the incompatibilities are documented and there have been a few efforts before to get these things sorted out. I also contributed some of the patches or tried to push Selectrum a bit in that direction over the last few months.

Personally, I moved over to Vertico, which is as simple as possible (I believe) and embraces the Emacs filtering mechanism. For this reason Vertico is incompatible with Prescient, since Prescient uses its own filtering API. Vertico started as an experiment on how the dynamic table support could be implemented in Selectrum and then it turned out that this is easy enough to just make it a full completion UI, which is automatically fully compatible. It turns out that the Emacs filtering infrastructure is pretty rigid - you don't have many degrees of freedom to implement a completion UI if you care about full compatibility. When Selectrum was started, it was designed as a clean-slate completion system. It must be retrofitted to support all the Emacs completion features on top of its clean-slate architecture. From my perspective most of the original advantages of the clean-slate design are gone as soon as you support all the Emacs completion features, leading to a more complex system overall.