Alternative crm idea #160
Comments
|
Instead of writing a separate |
|
Yes; this is basically @clemera's original idea!! Is there a way, or could you extend it, to then deselect? To be clear, for my case, I don't imagine deselection would be a common need, but say I make a mistake, and need to remove a candidate. A similar case could be the cc field for an email.
+100. With this approach, then I could also rely on ... plus the fact there is no Right? In any case, if you do put together a branch/PR for Consult for this, I'm happy to continue the discussion to figure out the details! |
|
Deselect already works if you select the item again. Regarding consult my idea was to provide a function consult-completing-read-multiple which is NOT supposed to be used by packages. It is meant as replacement for completing-read-multiple to be set in the user configuration (advice override). |
|
Deselect already works if you select the item again.
OIC. I like it.
So how would that work in the doom and its biblio module case, which is
kind of midway between packages and user config?
I only know enough about advice to know it can be dangerous if you don't know what you're doing.
And practically speaking, that would involve no changes to this package?
|
|
In your package here you would just continue to use crm without any trickery. And then if the user configures consult appropriately, the enhanced version will be used. Doom could be configured to use consult-completing-read-multiple as drop-in replacement if compleseus is used ;) |
I can't see any way this wouldn't be a preferable interface to CRM, TBH, even for short candidate strings. So that would be my preference. WDYT @iyefrat? What @minad is proposing here is basically the ideas we earlier discussed for selectrum, but in this case would work for selectrum, vertico, etc. Certainly for bibtex-actions, the improvement would be dramatic. |
|
I will try to prototype this for consult and then we can see if this works out. |
|
Just notes as I'm playing with it; I'll probably edit this if other thoughts occur to me:
|
See here for the current consult version: https://github.com/minad/consult/tree/crm |
Now, we use "initial-input" to filter the candidate list. For example, for the command I actually think it works pretty well, notwithstanding the CRM issue with it. I think @mohkale had been experimenting with narrowing to do the same thing. That's what motivated that question, and also why he was earlier asking about CRM support for Consult.
👍 |
|
An initial test with bibtex-actions is really encouraging @minad! I see the TODO notes in the code. When and how do you want further feedback? |
|
You can give feedback right away. But I am still not sure about this. There are multiple issues.
But overall I think |
|
|
OK.
|
|
@ilupin @publicimageltd - you two might be interested in this. Here's what it looks like with bibtex-actions:
|
|
I am playing around with this and I am still not happy with it. Two other issues:
|
|
I may try a different approach now, taking Embark actions as inspiration. I bind a select command to TAB in the minibuffer for |
Agree.
Would it be feasible to also have a modifier ( See: |
|
Can the "not selected" group be unnamed? Should it? |
|
On this ...
... do you mean by using a predicate; like: (lambda (x) (string-match-p "has:pdf" x)) |
|
I experimented with this a bit longer. I tried also to implement a prototype in Vertico directly. But somehow I am not satisfied with the outcome. Either I implement the
|
|
My recommendation for your project is to use your own (defun simple-crm (prompt candidates history)
(let ((selected)
(items candidates)
(history-items (symbol-value history)))
(while
(progn
(set history (append (mapcar #'substring-no-properties selected) history-items))
(let ((item
(completing-read
(format "%s (%s selected): " prompt
(length selected))
(lambda (str pred action)
(if (eq action 'metadata)
`(metadata (group-function
. ,(lambda (cand transform)
(cond
(transform cand)
((get-text-property 0 'simple-crm-selected cand) "Selected")
(t "Not selected")))))
(complete-with-action action items str pred)))
nil
t
nil
history
"")))
(unless (equal item "")
(if (member item selected)
(setq selected (delete item selected))
(setq selected (nconc selected
(list (propertize item 'face 'region
'simple-crm-selected t)))))
(setq items
(append selected
(seq-remove (lambda (x)
(member x selected))
candidates)))
t))))
selected))
(simple-crm "Select multiple" '("first" "second" "third" "fourth") 'minibuffer-history) |
|
Ok, thank you for taking the time to give it a try. Just to clarify ...
So you could not get this approach to address those issues. With a solution specific to vertico or selectrum, you can, but that certainly conflicts with the minimalism of vertico (but selectrum?). It also requires different code. If the above is all true, it sounds like even I might not include this per se; maybe put it on the wiki or README initially, and encourage people to experiment with it?
|
This comment has been minimized.
This comment has been minimized.
I cannot get these issues to be fixed reliably as part of Consult, which has to treat the completion UI as abstract. If I solve it inside the UI package itself (Selectrum/Vertico/whatever), then I can of course make it work.
No, that's not the only problem. If I would find a satisfactory solution, I would not oppose adding it to Vertico. The intrusiveness/non-minimalism is just one factor. The bigger problem is that I am not actually sure how the crm UI should look like. On the level of Vertico I can do everything, since I control the full UI. This opens a large space of design freedom and I don't know what I want exactly. The prototypes
Of course, I could do this. Maybe it is a bit too complex for the wiki? My proposal is that you add your own implementation here based on
Yes,
|
|
To give you a picture of the design possibilities.
|
Of course.
Regarding the Helm model, I forgot to state my criticism. The problem with this model is that it is very inconvenient if you want to unselect candidates if you have many candidates. Either you have to search again for the selected candidates by scrolling through the long list or you have to input the filter string again. For this reason, I dismissed this approach right away, the models I've proposed above (1-4) all separate selected/non-selected items by grouping. Unfortunately this introduces the problem, that the user has to move across these candidates every time.
I think my example 4 would indeed be pretty good. Unfortunately this model would be quite complicated to implement and deviate a lot from how Vertico works now. The minimalism is holding me back on this one. This will introduce another new set of problems/features. As I said one may want to have the select all feature/select by holding down shift. Then one may want to integrate this with Embark, which would require heavy changes there, since Embark fundamentally acts on single candidates. If you want to act on more than one candidate, use Also note that multi selection will not work for The
Yes, my proposal is to start from #160 (comment). |
|
@publicimageltd did raise the possibility of just ditching multiple selection altogether, or least for the commands that don't really need it. Citation insertion is probably the most important place where a clean and efficient multi-selection UI is important, and it's probably the most important command for authors. The new almost-ready-to-mainline native "org-cite" module, interestingly, uses CRM for the initial insertion, and then CR for editing existing citations. I may, for example, borrow from that for org. It has also occurred to me, as you note, that |
I started the linked PR. Is it possible to fix any of this in simple-crm? Or does your conclusion above apply to this as well? |
|
No, these issues are not fixable in simple-crm. But the issues are not severe. It depends on the use case. I think for bibtex-action the benefits outweigh the downsides. |
|
It's fun to follow that conversation. It shows that helm actually has a USP, and it also shows, in my eyes, that multiple selection is actually not such a clear concept. I agree with @minad that multiple selection soon raises the demand for more advanced possibilities, such as selecting with shift hold, so that there is no clear cut between minibuffer selection and a complete selection UI which mimicks dired or whatever. I like the proposed implentation 4, however. Why not just use the entries above the prompt as sort of FIFO stack? If we select something, we can push it onto the stack; there is some easy way to pop it (say, by moving the cursor up); but no further thrills: no filtering, no nifty selection of candidates. After all, this interface is not meant to deal with so many entries; I think that's one main result from the discussion. It's more of a shortcut. And thinking about such a way of handling things, why not doing something like "live insert"? The idea is: We select an item, and it gets inserted (and maybe removed from the candidates list). But we stay on the prompt. Now we can either insert another item, or do something to undo the last insertion. Such a behavior could be triggered by using modifier keys (M-RETURN instead of RETURN), don't know. That would not be a CRM interface, but something which would be quite intuitive to use, once we get a good keybinding. And it would solve @bdarcus concrete problem, since that is focussed on the task of inserting a list of citations in a buffer. |
Yes, nobody doubts that helm has its unique features. Multi-selection is probably the most unique concept. Every other concept is to some extent available elsewhere. But the multi-selection concept is not present in Emacs completion itself, except for
Yes, this is probably the best proposal for crm. But it will be a significant effort and in the end it will only raise the demand for more advanced possibilities as you said. Therefore my current stance is to not implement such advanced multi completion stuff and focus on single completion. This focus is not unreasonable given that
I must admit I don't understand your proposal. It is not concrete enough. I am arguing on a very concrete implementation level here, I have a very clear idea how all the models I've shown above can be implemented. For example (1) is the simple-crm/consult-completing-read-multiple implementation from above. For (3) I have a Vertico prototype, (5) can be implemented in Vertico directly or on the level of crm/consult-completing-read-multiple. (4) is significantly more effort, it can only be implemented in Vertico and it will be intrusive. |
You mean on an implementation level, or as a possible UI? |
|
From UI POV, might it basically mean using CR, but having some key binding that keeps the minibuffer open with the search string, but that the candidate gets passed to CR behind the scenes? So if one has to insert a citation with three keys, rather than calling the command three times, you call it once, but select each key in turn? Is something like that WYM @publicimageltd? |
This is similar to #160 (comment). One would end up with an UI like (5) I suppose, where the selected candidates are marked? This is not complicated to implement, but I don't find it satisfactory since you don't see the selected candidates at a single spot. |
Yes, that was the idea. Basically a
You do: in the buffer where the candidates have been inserted. |
Right, that works for this case (in buffer insertion), but doesn't generalize; does it? |
|
Actually, I was toying around with a similar idea to implement something like hierarchical list selection. The idea is to somehow have two ways of "selection": one meaning "do action and quit", and the other one "do action and repeat with a modified set of candidates." |
You are right, it's quite specific in that respect. |
|
Ah okay, now I get it. This is totally dependent on bibtex-actions then, just like calling |
It depends on how the second type of selection ('do action and repeat') is communicated. I had toyed around with a similar idea a while ago, and looking at the code, it seemed like one needs a global variable which is set before calling |
|
FWIW, my experiments with the capf were to provide another way to do citation insertion and editing. It doesn't work correctly on my end ATM though. I'll fix it when org-cite is merged. |
And maybe that's the best way to do it. It's more clearly centered on the buffer text and does not demand any new knowledge of alternative keybindings to select an item. I still like my idea, however. It could be useful for browsing through hierarchical lists, like notes in org-roam, or imenu. I imagine a kind of "folder" like experience of pressing, say, tab on an item, and then a sublist opens up. And pressing shift-tab, and we're back in the old candidate list. If @minad knows a way to solve the problem how to communicate the two styles of selection to the calling loop, I might try that for |
|
FYI, the branch now works, if anyone wants to test it. Details at #163. |
|
Thanks for working and thinking about this
I have been a long-time helm user and have used a similar looping completion (from the initial discussions in helm here and here) but for adding org tags in my This actually implements the stack idea by putting the already selected candidates at the end, but mostly I never see them when selected because the list is too long. This is all a bit of a hack, modifies the completion list after each selection, and is probably not terribly efficient (now that I try to migrate from helm to the much faster machinery of newer packages, I am considering reimplementing this, but just realized that CRM is still a mess, thanks for enlightening me in this thread).
I will gladly try out your new branch @bdarcus. I guess a source of inspiration could also be what Zotero (or perhaps some of the commercial bibliography managers) does for inserting citations (https://www.zotero.org/support/libreoffice_writer_plugin_usage). It can also be said to implement the stack idea, but my emacs-tuned fingers have never really liked it. |
|
@andersjohansson This issue here is about something different than the org tags issue. The problem with the org tags command is that it uses a badly written dynamic completion table. This completion table basically only works with default completion (tab completion and the The problem here is that bibtex-actions has special requirements due to its very long candidate strings. The default crm implementation is insufficient for this use case. Either a replacement for CRM or the looping CR could be a solution. |
|
@andersjohansson This issue is about something different. completing-read-multiple works perfectly for short candidate strings (org tags, mail addresses etc) with Vertico or Selectrum.
The problem with the org tags command is that it uses a badly written dynamic completion table. This completion table basically only works with default completion (tab completion and the *Completions* buffer). If org would use CRM for that everything would be alright. See https://github.com/minad/vertico#org-set-tags-command for more information.
You are right, of course. I could probably easily rewrite my library using completing-read-multiple then, since I actually generate the completion-table separately from org anyway.
Thanks!
|
|
Thinking more about option 4. Notwithstanding implementation challenges, that I can't assess ...
I think it's safe to say this would be the case. But that's not a terrible idea; just a question where to draw the line.
Does the embark discussion on #163 address this? From a UI POV wouldn't it be the case that for CR things could be exactly the same?
This is the chicken-egg issue I earlier mentioned. Perhaps with this sort of UI, more commands would use CRM? |
|
While 4 may be a nice solution, it is restricted to Vertico. It cannot be implemented generically in consult. It would change vertico too much and affect every part of it. I don't want vertico to become a multi selection system. In contrast simple-crm/consult-crm is a single isolated function (good cost/benefit ratio). But if it isn't good enough then it may not make sense to add it to consult. The embark issues are orthogonal to this whole discussion. For any of the discussed UIs one could enhance embark multi selection support, but I would also prefer the simplest possible solution. For example I would avoid complicating the embark calling convention. |
|
Current consult-completing-read-multiple version: https://github.com/minad/consult/blob/71045e7ac27ce6c88abc0809e48eef5393497d7d/consult.el#L2154-L2250 Does not support Embark yet, still have to figure out how to do this. Besides that, I think it works well enough. |
Just FYI, this was just fixed. Org tags now uses CRM. |
I thought maybe it is better to give up on crm and use something else based directly on
completing-read. Try this:Fortunately there is also no need to implement a custom completion table. I wonder if such a functionality deserves to be provided by some package.
The text was updated successfully, but these errors were encountered: