Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Find solution for initial-value multiple problem #144

Closed
bdarcus opened this issue Jun 15, 2021 · 13 comments
Closed

Find solution for initial-value multiple problem #144

bdarcus opened this issue Jun 15, 2021 · 13 comments
Labels
Milestone

Comments

@bdarcus
Copy link
Contributor

bdarcus commented Jun 15, 2021

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.

@bdarcus bdarcus added this to the future milestone Jun 15, 2021
@ilupin
Copy link
Contributor

ilupin commented Jun 16, 2021

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
Copy link
Contributor Author

bdarcus commented Jun 16, 2021

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
Copy link
Contributor

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
Copy link
Contributor Author

bdarcus commented Jun 16, 2021

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
Copy link
Contributor

publicimageltd commented Jun 16, 2021

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
Copy link
Contributor Author

bdarcus commented Jun 16, 2021

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
Copy link
Contributor

minad commented Jul 7, 2021

@bdarcus This has been fixed now too?

@bdarcus
Copy link
Contributor Author

bdarcus commented Jul 7, 2021

@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
Copy link
Contributor

minad commented Jul 8, 2021

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
Copy link
Contributor Author

bdarcus commented Jul 8, 2021

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
Copy link
Contributor

minad commented Jul 8, 2021

@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
Copy link
Contributor Author

bdarcus commented Jul 8, 2021

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.

@bdarcus
Copy link
Contributor Author

bdarcus commented Jul 30, 2021

My "solution" was just to remove it :-)

See #194.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants