Hitting <RET> with only candidate should select it

[artagnon]

Using C-j to open a file with that name literally, like in Helm.

[Osmose]

So if I have a path /foo/bar/baz in the input, and the list of candidates has /foo/bar/bazbiff as the only entry, you want <RET> to open /foo/bar/bazbiff?

I'm not sure I agree that that's what we should do. To me it seems more natural that hitting <RET> honors what is in the input box, and that to open the only match you need to hit <TAB> first to finish the path. It matches how most shell prompts work.

Maybe we can add a command that has that behavior so power users who want that behavior can bind a key to it?

[artagnon]

Hm, I'd urge you to think about: do you select completion candidates more often, or create new files more? Overwhelmingly, it's the former, so that's why I want to optimize for it.

Sure, I don't mind it being optional, but I'm seeing some problems here. The visual cue of the first item always being selected, but not activated on ( acts on the text in the box instead) is confusing, no? So, let's not do a visual cue then. Upon C-i, we'll act as a superset of -- it either acts on whatever is selected, or acts on the first item if nothing is selected. I'll bind it to for my purposes.

What do you think?

[Osmose]

Will comment more later, but one small question:

The visual cue of the first item always being selected, but not activated on ( acts on the text in the box instead) is confusing, no?

The first item isn't always selected, is it? I don't see any selection until I use the arrow keys to scroll through the list.

[artagnon]

Ugh, sorry for the confusion. I meant: "if we were to implement this feature naively, then

The visual cue of the first item always being selected, but not activated on ( acts on the text in the box instead) is confusing, no?

"

s/is/would be/.

Also, should we think about fuzzy matching and scoring results? (I know cmd-p already does this, so it's just a matter of hooking up the code)

[Osmose]

Also, should we think about fuzzy matching and scoring results? (I know cmd-p already does this, so it's just a matter of hooking up the code)

It's a neat idea for a default-off preference, as I think mimicking what the average command prompt does is best for our defaults. But fuzzy matching would also be super-useful to folks who understand it.

[Osmose]

Hm, I'd urge you to think about: do you select completion candidates more often, or create new files more? Overwhelmingly, it's the former, so that's why I want to optimize for it.

Agreed that selecting completion candidates happens more often, but I think consistency is more important to our UX than optimization.

I like to think of it as state in the user's head. The less rules about what the return key does that the user has to remember, the more natural it will feel. In this case, we reduce state that the return key depends on by removing the dependence on the autocomplete results.

(From this standpoint, I'm not entirely happy with what we do now around Return either opening the current path or the selected path, but I haven't yet come up with an arrangement that I like there.)

But you're totally right that, for a user who has no problem remembering those rules, we can make things quicker and easier. That's why I favor it as a configurable command.

Upon C-i, we'll act as a superset of -- it either acts on whatever is selected, or acts on the first item if nothing is selected.

That sounds great to me.

[artagnon]

Yeah, you're right about the consistency thing. It's not about picking the most locally optimal keybindings -- it's about giving the user a smooth experience so that she rarely hits the wrong keys. I did hate Linux/Emacs for the inconsistency.