Find solution for initial-value multiple problem

[bdarcus]

Awhile back, we added initial-value support to pre-filter candidates based on the presence of pdfs, links, notes.

This is simple, works well for its purposes, and is flexible.

But it doesn't work well in the case of multiple candidate selections.

@mohkale has separately experimented with using grouping with consult filtering, but this also doesn't work with multiple selections, as consult--read is single selection only.

Aside: I'm also not convinced grouping is the right UI for this use case.

In this issue, Daniel Mendler suggested writing our own custom CRM-like completion table to do what we want (but with the caveat IIUC: it won't currently work correctly in selectrum, which may make it a deal-breaker).

minad/vertico#59 (comment)
minad/vertico#59 (comment)

I don't know if I have the skill to do that, and I definitely don't have the time in the near future, but worth considering at some point.

cc @ilupin and @publicimageltd just so they are aware of the conversation

PS - I tagged this with a "future" milestone to indicate it's not important to address now.

[ilupin]

Awhile back, we added initial-value support to pre-filter candidates based on the presence of pdfs, links, notes.

What do you think about filtering candidates at this line?

https://github.com/bdarcus/bibtex-actions/blob/07a3c64b12673b722a21c932eb85c595dea0c863/bibtex-actions.el#L225

For example

(seq-filter (lambda (x) (string-match "has:pdf" (car x)))
            (bibtex-actions--get-candidates))

In addition, "has:pdf" could be added to the prompt to indicate the filtering.

[bdarcus]

What do you think about filtering candidates at this line?

We talked about something like that, but the downside (correct me if I'm wrong) is one can't then remove that and get the full candidate list, which you can do with initial-input.

The use-case for that greater flexibility is let's say you start by wanting to open a document, and so get a subset, but then change your mind and want an action which requires access to the full candidate list; say inserting a citation, or opening a new note.

That's why the current design.

WDYT?

[publicimageltd]

The use-case for that greater flexibility is let's say you start by wanting to open a document, and so get a subset, but then change your mind and want an action which requires access to the full candidate list; say inserting a citation, or opening a new note.

To me, what makes the current implementation useful is not the ability to change the action (that would be too much for one command), but the ability to widen the scope of possible targets. And I have actually only one use case where this is used on a daily basis: I look for a pdf and find out there is none.

So maybe we should reflect on other possible use cases in order to estimate if this flexibility is really so useful, if it poses problems. OTOH, I don't really see such a big advantage in using completing-read-multiple. I won't open many pdfs in one row, or visit many bibtex entries at once. Also, such a behavior (mass actions) can also be had using embark snapshots.

[bdarcus]

Yes, your example is better than the one I posted. That's actually the one that bothered me earlier.

I think multiple is definitely right for this situation. My primary case for that is inserting citations, but opening notes can also be useful.

It's just unfortunate the CRM UIs suck, and developers seem to ignore it.

[publicimageltd]

Well, then why not just use multiple completion for bibtex-actions-insert-citation? After all, the interactive spec in this function makes no use of initial input. So there's no conflict. That would cover a case which sounds like people would use it often.

[bdarcus]

Well, then why not just use multiple completion for bibtex-actions-insert-citation? After all, the interactive spec in this function makes no use of initial input. So there's no conflict. That would cover a case which sounds like people would use it often.

That may be worth considering, but I'm still holding out for a proper UI fix for CRM:

radian-software/selectrum#489

[minad]

@bdarcus This has been fixed now too?

[bdarcus]

@bdarcus This has been fixed now too?

@minad - no.

This is referring to our earlier discussion, where I was wanting the initial-input value to apply to all selections, and you said that was abusing initial-input.

So one fix is as you suggested, pre-filtering, but then we lose the flexibility of being able to remove the filtering, which @publicimageltd explains well above: #144 (comment).

I will probably change these "open" commands to use completing-read, which when coupled with Embark would allow us to keep initial-input, since it doesn't seem there are other, better, alternatives to keep what's valuable about it?

[minad]

Okay right. For this to work we need again the S-TAB/TAB distinction which allows to keep the input intact. I will take another look at this.

[bdarcus]

I had forgotten where I had seen this, but now stumbled on it. This approach uses Consult narrowing/grouping.

tmalsburg/helm-bibtex#361 (comment)

As I said elsewhere, not convinced it's the right UI for this, but it has the same advantages as the initial-input approach.

[minad]

@bdarcus Regarding the UI-specific keybindings: I removed them for now to keep things simple in Consult. My goal in Consult is too keep the integration code to the different UIs minimal, since this is crucial to keep things maintainable. Look at this commit - minad/consult@49b6442. Half of the integration code with Vertico was only due to consult-completing-read-multiple. This is hardly justified. Therefore my current plan is to not support any kind of special keybindings for improved interaction beyond RET, which works for all UIs.

I also experimented with a consult-completing-read-multiple variant in a separate package, independent from Consult (https://github.com/minad/consult/blob/separate-crm/multisel.el). But I will probably not push this further since in the end it will fundamentally still not be a fully correct and fully general solution due to the lack of support of dynamic completion tables/completion boundaries, as I've described before (see minad/vertico#74 (comment) and minad/vertico#74 (comment)).

So to conclude this - consult-completing-read-multiple will intentionally remain a simplistic implementation and will intentionally only support the RET interaction. I like the simplicity of it and I still think it is a neat improvement over the default crm.el implementation. I think we should explore the direction of Embark further regarding multi candidate handling. I think this direction is potentially more fruitful.

[bdarcus]

That's totally reasonable @minad.

I added a prominent recommendation for consult-completing-read-multiple on this README, but I'm not specific on details like keybindings. I'm sure people will be happy with it regardless.