Alternative multiple candidate select UI?

[bdarcus]

I'm working on this package, which is sort of a port of helm-bibtex to completing-read, aimed at selectrum (and icomplete-vertical).

My core completion function uses completing-read, but I think I need to change it to use completing-read-multiple, as the backend functions all take multiple keys as parameter.

But I don't think selectrum's current UI for this will work, as the completion strings are very long.

Notice what happens in this screenshot at the top:

Now, compare to helm-bibtex, where one does ctrl-space to mark the candidates.

Is there any reason this wouldn't be a more general and consistent approach?

If not, is there any workaround you can suggest?

cc oantolin/embark#166 emacs-citar/citar#17

[clemera]

We could think about combing both approaches, we had a selection feature in the early days see the #74 for more discussion about the current UI.

[clemera]

Right now the candidates are simply removed from the list, maybe it would be better to leave them there but show them selected?

[clemera]

Hm, I don't think there would be a benefit, could you describe more what you don't like about the current UI? Maybe you are just annoyed about the scrolling of the prompt as the candidates are so long?

[minad]

Yes, the candidates are too long. Given a vertical ui long candidates are common. People are developing applications which produce long candidates as in this case with bibtex.

[clemera]

The prompt gets scrolled for me in this case.

[clemera]

Maybe it is a problem when you want to inspect your selections visually or am I missing something?

[bdarcus]

I took a quick look at #74 (thanks), but it seemed like @oantolin's critiques of the earlier UI (which I never saw) were more implementation than basic concept?

Hm, I don't think there would be a benefit, could you describe more what you don't like about the current UI? Maybe you are just annoyed about the scrolling of the prompt as the candidates are so long?

It's more than "annoyed"; it seems initially completely impractical for this use case :-)

Let me elaborate on the use case.

When writing book or article manuscript, I need to be able to very quickly and easily, so as to avoid interrupting the writing process, select and insert citations.

Sometimes citations have one key, often more.

With the helm-bibtex UI, it's the same UI for one candidate as it is for multiple; the only difference is a keybinding to select multiple.

I can instantly see what I have selected, and so what citation will be inserted at point.

Not so with selectrum. I can only see one selection at a time, and I have to switch UI context to be able to scroll.

Perhaps different selection UIs are optimized for different use cases?

@clemera (who posted this after I started replying)

Maybe it is a problem when you want to inspect your selections visually or am I missing something?

Yes. Say I have 2000 references in my bibtex file(s). I need to be able to select the exact three that I need to insert as a citation at point, and those may be pretty similar to others I don't want (same author, say). Being able to see all I have selected at once allows me to confirm I have the right ones.

Does that explain better?

[clemera]

I see, another improvement in this use case would be to select multiple items without resetting the input between as discussed in #395 (I forgot about that one and I also needed some explanation there, I just have no such use case 😆) so you can pick the similar items right away without repeating previous inputs.

[clemera]

The previous UI worked similar to what you are suggesting, the critique by @oantolin back then was also about the UI itself, there are use cases for both it would be nice to allow both in tandem is some way.

[oantolin]

@bdarcus

I can instantly see what I have selected, and so what citation will be inserted at point.

Is that really true in Helm? Does it move selected candidates closer together or something? I thought that if you had 2000 references in your bibtex file and you wanted to cite references 21, 803 and 1831 you could not see in Helm at a glance which were selected, you'd have to scroll like a madman to see which one are selected. Am I wrong?

EDIT: Well, I guess if all the chosen references have some text in common, you could type that into Helm to bring the selected ones closer to each other.

[bdarcus]

Is that really true in Helm? Does it move selected candidates closer together or something?

Oh, good question @oantolin. No, it doesn't.

In that workflow, I'm assuming I'd narrow to some manageable subset.

Well, I guess if all the chosen references have some text in common, you could type that into Helm to bring the selected ones closer to each other.

Yes, this.

The most common case is I'm citing a person's work, for example, so I narrow on the references of that person.

[minad]

What about moving the selected items to the top such that they are always visible if not scrolled out of sight?

[bdarcus]

What about moving the selected items to the top such that they are always visible if not scrolled out of sight?

First thought is that would be an improvement on the helm version.

[oantolin]

I think that for this particular situation, I'd like the standard completing-read-multiple interface but with each selected candidate displayed as just the bibtex key. The only issue right now is that the text in the minibuffer prompt is too long, no?

[clemera]

@oantolin Currently the input resets after inserting a candidate with ´TAB` so the previous search matches are gone, if you want to select multiple similar candidates (contained in you current set of matches) you need to input the same text again, for this use case selection would be more convenient.