I was curious about integrating avy with selectrum and found #16 and the selectrum-show-indices solution works well for me. But I'd prefer not to display indices all the time. How about an interactive command to toggle selectrum-show-indices bound to a key in selectrum-minibuffer-map the way M-s SPC toggles lax space matching in isearch?
Yeah, that seems reasonable to me. Even if it's not used commonly, the implementation would be very simple, so it probably wouldn't have a high maintenance cost.
The question would be whether there is a sensible binding for this by default, or whether we should advise people to create a binding themselves if they want to use it regularly (with recursive minibuffers enabled, you can still run the command even without a binding).
I'm using selectrum with marginalia, consult and embark. I'm liking them a lot and appreciate that they don't depend on each other. But for all of them, I'm starting to see a few commands like this that I'd like to toggle some behavior. Things like: showing indicies in selectrum, toggling previewing in consult, cycling annotation levels in marginalia. I'm not sure if these packages will install bindings for these or just make configuration suggestions, but it would be great if they can all put such commands on bindings with similar prefixes. I'm trying to put them all on a M-M-t.
I think that ideally we could establish a convention of using a specific prefix key for these commands. One of the things I like about the Selectrum (and CTRLF) paradigm is that normal bindings work the way they should, and by avoiding using top-level bindings, we can preserve that property. For example, it would probably annoy me if M-t were bound by default---I sometimes want to transpose words in the minibuffer, which is the standard function of M-t.
This would be somewhat like the M-s prefix that Isearch uses for its advanced bindings, which we have reused in CTRLF for binding toggle commands.
Yes I recently discovered that selectrum-prescient binds toggles on M-s and like it. Finding free keys for binding and naming things are the two hardest things in emacs. But maybe a few conventions and some coordination can make these packages mesh well together. Even if the bindings are just recommendations in the READMEs, it would be great if selectrum/consult/marginalia/embark/orderless played well together and didn't recommend ones that conflict.
The packages I am (co-)maintaining, marginalia and consult will not bind any keys. But we can surely add recommendations to the example config as we are already doing.
I should add - I also won't recommend intrusive keybindings like M-t, I would lobby against that ;)
The packages I am (co-)maintaining, marginalia and consult will not bind any keys. But we can surely add recommendations to the example config as we are already doing.
I should add - I also won't recommend intrusive keybindings like M-t, I would lobby against that ;)
Same for Embark!
(Well, of course Embark has tons of key bindings! I mean it will not binding anything at top level, only in action maps and in major and minor mode maps ---so far, Embark Occur mode and the direct action minor mode.)
I will happy recommend key bindings in the README, of course.
I agree with your choices of not binding keys. All I meant by:
Even if the bindings are just recommendations in the READMEs, it would be great if selectrum/consult/marginalia/embark/orderless played well together and didn't recommend ones that conflict.
was that if, for example, the marginalia README had an example of binding marginalia-cycle to say M-s a that embark didn't also have an example of binding something to M-s a. So that if someone came to these packages and cut and pasted some configuration examples, they didn't conflict with each other unnecessarily.
This probably isn't the right issue for it but seeing as its the only one tangentially related to #16 I'd just like to say I'd still very much like an ivy-avy like command for selectrum. I've figured out how to get the currently visible candidates list but I'm not sure how to plug it into avy. Avy seems to use an alist of markers to determine where to jump but selectrum uses an overlay to display the avy candidates and read keys. Can you get markers to within an overlay?
@mohkale I have an avy like selection feature on my personal TODO list as I also would like to have it :) I think probably avy shouldn't be used for this, I would go for a custom command which sets a flag to show the keys which then adjusts the display string, reads a key and chooses the index based on that key.
@clemera
I see. That's great. I look forward to this, lemme know if there's anything I can do to help :-)
Another disadvantage of not having your completions in a normal buffer. 馃槈 avy-embark-collect was trivial to implement. 馃槢
(defvar selectrum-avy-keys '("a" "s" "d" "f" "h" "j" "k" "l" "g" "h"))
(defun selectrum-avy ()
(interactive)
(let* ((keys (if (< (length selectrum-avy-keys)
selectrum--actual-num-candidates-displayed)
(let ((combs ()))
(dolist (key1 selectrum-avy-keys)
(dolist (key2 selectrum-avy-keys)
(push (concat key1 key2) combs)))
(nreverse combs))
selectrum-avy-keys))
(len (length (car keys)))
(selectrum-show-indices
(lambda (i) (or (nth (1- i) keys) " "))))
(selectrum--update)
(when-let* ((pressed
(let ((inhibit-quit t))
(cl-loop repeat len
for input = (read-char)
if (eq input ?\C-g)
return nil
else
collect (char-to-string input))))
(res (apply #'concat pressed))
(pos (cl-position res keys :test #'string=)))
(selectrum--exit-with
(selectrum--get-candidate
(+ selectrum--first-index-displayed pos))))))
Adding the selectrum-avy-keys variable involved adding one if clause in Selectrum. I will not do it exactly like this, but I think this counts as trivial, too ;)
EDIT: @mohkale I updated the version above, you can use that as long there is no built-in available.
I still think selectrum should come with an easy built in way to toggle indicies, but FWIW this is working okay for me. It wasn't obvious that showing indicies doesn't just show them, but enables their selection with M-NUM RET or C-NUM RET. I do still think an avy solution would be better as it would work with more than 10 candidates and use slightly fewer keystrokes but a selectrum solution that did similar (choose indices for number of candidates shown, maybe not just numbers as avy does; displays them just for the current command, not the next; and allows single key selection without RET) would be great.
(defun hrm-selectrum-toggle-show-indices ()
"Toggles avy-like behavior in selectrum minibuffers."
(interactive)
(setq selectrum-show-indices (not selectrum-show-indices)))
;; oddly, enabling selectrum-mode doesn't load selectrum, see selectrum.el
(with-eval-after-load "selectrum"
(define-key selectrum-minibuffer-map (kbd "C-'") 'hrm-selectrum-toggle-show-indices)) ; or s-t?
@hmelman With #479 merged can this be closed?
Probably. I'll play with it when it hits melpa.
Yes, this works just like avy, very nice. I appreciate the rationale for the default keybindings. I hadn't considered the difference between those two cases. I see M-i as useful when completing interim directory names, are there other uses?
I do wonder if there's a way to make the quick key appear appear before the item, the way the indicies do. I know you're using a display property like avy, but it does overwrite the first letter of the item making it harder to see and in this case there's usually plenty of room to not have to overwrite text.
I see M-i as useful when completing interim directory names, are there other uses?
One other use case is when adding candidates in completing-read-multiple.
I do wonder if there's a way to make the quick key appear appear before the item, the way the indicies do.
I assumed the user is already looking at the candidate and so avoiding any pushing of the candidates would be nicer but that is just my preference, you can open an issue for that if you like and I will add an option it.
Do the quick keys fulfill the role you wanted from an indices toggle so we can close this issue?
Do the quick keys fulfill the role you wanted from an indices toggle so we can close this issue?
Yes.
Most helpful comment
Adding the
selectrum-avy-keysvariable involved adding one if clause in Selectrum. I will not do it exactly like this, but I think this counts as trivial, too ;)EDIT: @mohkale I updated the version above, you can use that as long there is no built-in available.