Allow retaining input string after selection with citar-select-refs

[bdarcus]

From mastodon.

Sometimes I want to select several of the citations from the sublist resulting from entering "magloop" as the pattern/search string. This works but every time I press Tab to select a citation, the search string disappears and I have to type it in again. Is there a way to add a citation to list of selected ones and leave the the search string in place?

I think we'd want to allow a modifier key on TAB that would preserve the input, though I'm unsure how to do that ATM. Any ideas @aikrahguzar?

[aikrahguzar]

I have wanted this on occasion but not enough to implement it! I think if we want to do it, we have to do what vertico-repeat does and keep track of the input in post-command-hook.

[bdarcus]

If it's not too complicated, it does seem like it'd be a nice usability enhancement.

[aikrahguzar]

If it's not too complicated, it does seem like it'd be a nice usability enhancement.

It shouldn't be too complicated and I might take a stab at this soonish. But this has got me thinking if vertico can provide a simple multiple selection command based on vertico-repeart. It has all the pieces in place for that.

[bdarcus]

Not sure how that would differ from the earlier CRM prototype (which last I checked is still in that report on the crm branch), but he abandoned that because there was one or two limitations he couldn't resolve, the details of which I can't remember clearly, but which I think related to dynamic tables.

[bdarcus]

Not sure, but this new 29 stuff may have some relevance?

https://robbmann.io/posts/emacs-29-completions/

[Jousimies]

This commit make citar-open-files cannot open pdf file on a select candidate.

The step I do: M-x citar-open-files, move to one candidate with arrow key instead of input any char to filter candidate, then enter to open file. The echo area display No associated files for nil, but I do have pdf file in chosen candidate.

I downgrade to commit a9fae9c , it works well.

[bdarcus]

Thanks @Jousimies!

@aikrahguzar - do you have time to take a look?

[aikrahguzar]

@aikrahguzar - do you have time to take a look?

Not any time soon I am afraid. I don't understand very well how citar-open-files works now. If someone can give a recipe for a misbehavior of citar--select-multiple I might be able to do something.

[bdarcus]

I don't understand very well how citar-open-files works now.

It just presents a list of paths for llbrary files associated with the key(s).

If someone can give a recipe for a misbehavior of citar--select-multiple I might be able to do something.

@Jousimies - can you do this?

I haven't yet been able to reproduce it.

[bdarcus]

FYI, @Jousimies, I reverted this for now.

[bdarcus]

I'm reopening this, because I reverted it without every figuring out a fix for the initial commit.

I'm not exactly sure how to re-implement this, since neither of us were able to reproduce the bug reported by @Jousimies.

I do consider this to be one obvious missing UX feature that I really want to add back though.

[aikrahguzar]

I'm not exactly sure how to re-implement this, since neither of us were able to reproduce the bug reported by @Jousimies.

My dim memory of what happened was that the code used a feature of completing-read that was new in Emacs 29. I think the easiest thing to do is to use the initial-input arg of the completing-read. It is technically deprecated but I don't think it is going away.