-
-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Copy to root of current Dired, not first candidate #4
Comments
Yes, I think this is intentional. The first candidate is selected and therefore the copy goes there. If you want to copy to the current directory you can select the prompt by moving upwards. Now the question is if this default behavior should be improved. Multiple options:
|
I see, thank you! Just thought I would bring it to your attention. |
Selectrum has the Yesterday I also did some small experiments with CRM (see the crm and crm2 branches). I tried:
But for now I also didn't merge any of this since I didn't find it that of a significant improvement over the status quo, where the completing-read-multiple completion table just does its thing and I am not interfering. I think of Vertico as an experiment in what I can do with a minimal implementation instead of aiming to provide the very best UI by replacing everything here and there. In contrast, Selectrum for example has advices tweaking many details. |
@protesilaos you could use |
@manuel-uberti Yes, thanks for mentioning it. This is the option to exit directly with the current input. Furthermore you could bind |
Very well! That should go in the docs then. And yes, I also bind |
This thing about always submitting the first candidate even when the minibuffer contains a perfectly valid directory really messes with muscle memory acquired from using default completion. (I know that it's sensible, consistent behavior, but my finger don't seem to understand that.) I believe Selectrum does it too and it's one of the reasons I never really took to Selectrum. I didn't know about the advice @minad mentioned. Does it really change that behavior for the special case of dired while keeping it in other circumstances? If so, that sounds terrible, at least vertico does it consistently. Also, I think there was a long discussion of this behavior in the Selectrum issue tracker. And yes, I do recommend binding exit-minibuffer. If I enjoyed other people deciding what I can and can't do in the privacy of my own computer, I wouldn't use Emacs. But more practically, not every function you find out there that uses require match has really thought carefully about what all the possible choices are. You hardly ever need it, but it's annoying to not have it bound when you do need it. (I used to use it slightly more back when I used minibuffer-force-complete, which in some unusual circumstances breaks down and doesn't let you exit; I wrote my own version of minibuffer-force-complete that really and truly always exits with the top completion and now I need exit-minibuffer only very rarely.) |
To which map[s] do you bind |
I bind it only in minibuffer-local-map. That way it is available in all situations, including when using Selectrum, which for some reason doesn't use minibuffer-local-completion-map or minibuffer-local-must-match-map. |
Good, thank you! |
Yes, this behavior can be perceived as problematic some times. But I wonder how you reconcile the two approaches then:
Regarding the keymaps. I am also using
This sounds like you have a different variant of |
@minad, about the keymaps: I don't really like how many different keymaps default completion has, so I think the approach in Vertico and Selectrum is absolutely fine. You could almost set
Those are not mutually exclusive, of course! I use orderless until I think I've narrowed things done enough and then press TAB. If there is a unique candidate, TAB will insert it. You can also set up TAB cycling, which I use with a threshold of 3, that way TAB also inserts the candidate if there are at most 3 matches and cycles among them. I find that a threshold of 3 is a very good balance, in that if there are more than 3 candidates it is usually less annoying to me to narrow further than to move among candidates. I also bind RET to a command that first checks to see if the minibuffer contents are a valid candidate and if so just exits the minibuffer, if they aren't a valid candidate, it inserts the top completion into the minibuffer and exits. This way when I'm sure I've narrowed enough, I just press RET and am done. The built-in You may ask, "how do you know if you have narrowed enough to press RET if you can't see the candidates?". It's really not a problem in practice: Consult's previews often confirm for me I have the right top candidate, memory often is good enough too, and in rare cases where I'm not sure, I can press TAB or popup an embark collect completions buffer (which I bind to
It is indeed very similar. As I said above the only difference is that if the minibuffer contents are a valid completion (as reported by That rule is very subtly different from "If the input matches a candidate exactly, Vertico already puts it at the top", because in this directory example, the portion of the input between the completion boundaries is empty, and the empty string is not one of the candidates, i.e., is not the name of a file in the current directory (usually). So your rule says that the directory plus an empty user input string is not valid and that you must add the top candidate; my rule says instead that the directory is valid on its own, and RET will choose it. And in this directory example it's not just the function I bind to RET that would select the directory, the default RET ( Here's the code I use, in case you are curious: (defun exit-with-top-completion ()
"Exit minibuffer with top completion candidate."
(interactive)
(let ((content (minibuffer-contents-no-properties)))
(unless (test-completion content
minibuffer-completion-table
minibuffer-completion-predicate)
(when-let ((completions (completion-all-sorted-completions)))
(delete-minibuffer-contents)
(insert
(concat
(substring content 0 (or (cdr (last completions)) 0))
(car completions)))))
(exit-minibuffer))) You'll notice another small difference with |
Oh, wow, I apologize for the length of that comment! |
By the way, I finally tried Vertico and it's fantastic. I think I like it better than Selectrum already. I think, if I'm honest, that my biggest complaint with Selectrum is how slow it is to use embark-act in a non-mini buffer. Try |
I still don't understand why Both Selectrum and Vertico have pretty poor formatting if you use Marginalia and a narrow Emacs frame (I think you guys probably always maximize!), so maybe I'll stick with not showing completions most of the time and using Embark with its orderly tabulated lists when I do want to see them, but I do like Vertico a lot, easily more than Icomplete-vertical, for example. |
@oantolin Thank you for your lengthy response. I agree with you that the two approaches are not mutually exclusive. If you remember for Capf/Company I wanted exactly that behavior since I am already initiating the search with TAB. But in the minibuffer I don't need the TAB since I can use up/down to go to the correct candidate instead of tabbing. Tabbing would essentially do the same.
I see. This is actually a reasonable rule which makes sense for completions with completion-boundaries, including file completion. Maybe I will adopt your rule. It is actually easy to do - select the prompt if the current input test-completes successfully and as long as no other candidate has been selected before explicity. You may have seen the vertico--keep variable which remembers if the user performed some manual selection.
Yes, but this is Emacs' fault ;) I am just following the spec. I don't want to unnecessarily deviate from the defaults. Users who feel patronized can use your version!
Yes, but this is Marginalia's fault ;) I could try to align all the annotations but this would not work well I guess, since for example the M-x keybinding annotations are supposed to be displayed directly after the candidates. Only the docstring is supposed to the right.
This is no wonder since Selectrum does not sort every time. As of now Selectrum does not support dynamic tables correctly since it just assumes that tables are static, Vertico instead recomputes and sorts every time. However I could also add a static table optimization to Vertico, by M-x prompt detection for example. But Vertico tries to avoid any hacks as much as possible. For me Vertico is mostly fast enough. Then I also have a But why Selectrum is slow for Embark, I have no idea! |
Do not select the prompt if the first candidate equals the input after the completion boundary. This avoids jumping between candidate and prompt. A candidate matching the input after the completion boundary will always be moved first. This is a refinement of the previous commit, see #4. It is getting a bit complicated unfortunately. Thank you for talking me into this, @oantolin...
Wow, Selectrum really does change this behavior just for dired, keeping it other instances. Seems a little weird. |
@oantolin Did you try the current Vertico prompt-selection branch? Maybe this behavior used there would make sense for Selectrum too. It seems to me that Selectrum already works mostly like this, thanks to how it determines what to select and maybe also thanks to the advice. But the rules are more complicated overall. |
Hello Daniel, I started experimenting with vertico to make some suggestions, as you requested. I found an issue where if you try to copy/rename from one Dired buffer to another, without providing any minibuffer input, it copies/renames to the first matching candidate.
Here is a scenario with
(setq dired-dwim-target t)
:If I hit RET it will copy the file to the
doc/
subdirectory instead of.
. Can you reproduce this?The text was updated successfully, but these errors were encountered: