Closed clemera closed 4 years ago
That's a good idea. I actually feel that completion UIs by default shouldn't sort (or, as I like to say, they should preserve the order), but given that several do, defensive tricks like this are a good idea. I implemented this in commit 7529c2b, please test.
Of course any given compeltion UI can decide to sort anyway, but I guess having a display-sort-function and a cycle-sort-function is at least a hint that the completion UI should refrain from sorting.
Thanks, works great! When my next PR gets merged into selectrum it will check for display-sort-function
and use it for sorting if present so completing-history
will work out of the box :)
Thanks, works great! When my next PR gets merged into selectrum it will check for
display-sort-function
and use it for sorting if present socompleting-history
will work out of the box :)
You're doing lots of great work Emacsifying Selectrum!
By the way, I'm not sure I understand when you are supposed to use display-sort-function
vs cycle-sort-function
. Inside Emacs I believe the *Completions*
buffer uses display-sort-function
, and Icomplete, Ido and plain old tab-cycling use cycle-sort-function
...
I guess since Selectrum doesn't actually cycle (like pressing down arrow at the end of the candidate list doesn't take you to the top, does it?), display-sort-function
might be the better choice.
By the way, I'm not sure I understand when you are supposed to use display-sort-function vs cycle-sort-function. Inside Emacs I believe the Completions buffer uses display-sort-function, and Icomplete, Ido and plain old tab-cycling use cycle-sort-function...
I believe the former is for UIs which display the completions and let you navigate through them and the latter one only for when you cycle through alternatives one by one. I'm not sure there are cases where you would want those to be different, though.
I guess since Selectrum doesn't actually cycle (like pressing down arrow at the end of the candidate list doesn't take you to the top, does it?), display-sort-function might be the better choice.
Yes Selectrum doesn't allow any cycling completion style but it might make sense to use cycle-sort-function
as a fallback, thanks for the idea.
I actually feel that completion UIs by default shouldn't sort (or, as I like to say, they should preserve the order), but given that several do, defensive tricks like this are a good idea.
I just discovered that completing-read-default
does sort, too. So if the command depends on sorting the metadata always needs to specify it.
I just discovered that
completing-read-default
does sort, too. So if the command depends on sorting the metadata always needs to specify it.
I don't think completing-read-default
does any sorting on its own, it basically just sets minibuffer-completion-table
and calls read-from-minibuffer
. Here's a screenshot with embark-completing-read
, which as you know is just completing-read-default
+ embark-live-occur
after a short delay:
The words are in the order I specified them, not sorted alphabetically like the *Completions*
buffers does, nor sorted by length as completion-all-sorted-completions
does.
However, people using completing-read-default
tend to rely on TAB
(minibuffer-complete
) and if that command decides to setup tab-cycling, then it calls completion-all-sorted-completions
. The command minibuffer-force-complete
(which I don't think is bound by default), also uses completion-all-sorted-completions
. So I guess that in practice, yes, most people using completing-read-default
wind up also using other commands that do sort the candidates. Is that what you meant?
So I guess that in practice, yes, most people using completing-read-default wind up also using other commands that do sort the candidates. Is that what you meant?
Yes, I shouldn't have mentioned completing-read-default
probably. The display of completions is sorted by default.
Would it make sense to provide
display-sort-function
identity
with metadata of the completion table to prevent history completion to be sorted?