Suggestion: enter as alias for tab in auto completion

[aral]

From muscle memory (from That Other Editor), I keep pressing enter to select the current completion.

Would this make a good alias for tab?

[the-mikedavis]

Enter used to have this behavior where it would select the active completion item but that was changed in #1704 because it prevents you from inserting a newline when the auto-complete menu is open. So for language like Elixir, if you have a completion item like do_foo and a low idle-timeout configured, typing the do keyword (which is always followed by a newline) and then hitting enter to insert a newline would only close the auto-complete menu and you would need to hit enter twice to insert a newline.

[aral]

@the-mikedavis I’ve had a bit more of a conscious think about this while coding today and here are some thoughts:

The scenario outlined in #1704 is definitely valid and I’d consider it an edge case. The workaround (double enter) isn’t really a difficult one.

On the other hand, by not having enter autocomplete, a whole lot of inconsistency is being introduced into the controls (and it affects the ability to reuse existing knowledge).

To illustrate:

If I want to select the first auto-completion item, I have to press tab

OK, so, I’ve learned that. Right, now I want to select the second auto-completion item. I know that what I have to do is select it and press tab.

Only that doesn’t select it, it just highlights the next item in the list.

OK, so how to I select any auto-completion item but the first one? It’s using enter.

So that’s the inconsistency that’s introduced.

tab makes perfect sense for highlighting the next auto-completion item in a list and enter makes perfect sense for selecting it. The problem is that it works that way for every completion item but the first one, where the meanings are reversed.

That’s quite a bit of cognitive load to introduce.

On the other hand, the workaround for #1704 (pressing enter twice) is still consistent with the way the enter key works elsewhere.

Also, tab doesn’t finalise an action anywhere else (it affects selection) as far as I can see, whereas the role of enter is to finalise an action (like choosing what to complete with).

So I’d suggest reverting the change in #1704.

[the-mikedavis]

The scenario outlined in #1704 is definitely valid and I’d consider it an edge case. The workaround (double enter) isn’t really a difficult one.

Double Enter isn't a workaround though. Without #1704, the behavior of Enter is unpredictable: if you're faster than auto-complete you must only press Enter once and if slower then twice.

Right, now I want to select the second auto-completion item. I know that what I have to do is select it and press tab. Only that doesn’t select it, it just highlights the next item in the list.

I don't understand the distinction between "select" and "highlight" here. They're the same thing.

The auto-completion menu UI element is not a prompt - it doesn't need input to accept one of the candidates. tab, shift+tab, C-n and C-p all change the text in the document to the candidate so in order to accept one of the candidates is tab until the text matches the candidate and then move on (press any other key except tab, shift+tab, C-n or C-p).

[the-mikedavis]

Oh actually I see the behavior I think you're talking about now: Enter closes the completion menu when you have a selection.

OK, so how to I select any auto-completion item but the first one? It’s using enter.

When the completion menu opens, you don't have any of the options selected (the UI displays this: none of the options are highlighted) so Enter passes through and is inserted when pressed. If you tab to any of the candidates, Enter closes the completion menu. It only closes the completion menu though, it's not necessary to hit Enter at all: tabbing to candidates replaces the text with them and you can just keep inserting and the completion menu will close automatically.

If anything, we might want to rebind the behavior of Enter (close the completion menu, do not revert the change, stay in insert mode) to a more obscure keybind since it is only useful to close the completion menu and closing the completion menu is almost always unnecessary.

[subatiq]

Probably related to this issue.

Is there an option to somehow configure autocompletion controls? I feel that I need too many keystrokes to select the first option.

What I mean is the autocompletion sorts the options like a fuzzy-finder, it feels nice to type gibberish, get the most relevant option up and just press Enter to select it (without going Tab -> Enter), like I did in That Other Editor.

Maybe there can be some flag to always select the top option? And if I don't need the autocompletion (which is usually not the case with a good language server), I can press Esc.

In my opinion the fluency of the code-writing increases that way. Maybe it's just me, but would be nice to get someone's opinion on that.

[akivajgordon]

I don't really have too much to add here, but I too have been struggling to get my brain to press Tab to select. I'm coming here from vim, using coc.nvim, and whenever I get the autocomplete menu and I want to choose the first item, I press Enter instead and I get a newline.

I'm not necessarily saying that the coc.nvim approach is the correct way. And I've only been using helix for about a week now, so perhaps I just need to give it some time for the adjustment, but something doesn't feel like it matches my brain's mental model of how the autocomplete behavior should be.

[alexniver]

Same issue to me. I come from neovim. with plugin nvim-cmp, when I see autocomplete menu, I just press Enter and auto choose the first item. Tab --> Enter seems a bit annoying

[KOGDev]

I would like to add that as someone new to modal editing and being unencumbered with a previous editors short cuts, I absolutely love how Helix handles auto complete. I appreciate that it is not intrusive. Having enter change behaviours if the autocomplete menu happens to be open is far more disruptive than using tab, since the majority of the time tabs are only relevant at the start of a line where autocomplete won't open, while typing enter for a newline happens at the end of lines where autocomplete is much more likely to be open. I also appreciate that tabbing through the list does not require any additional confirmation, pressing enter is totally redundant. In that regard I would be in favour of removing/remapping the enter keybinding as Michael suggests, as it isn't needed and seems to be causing confusion.

[idr4n]

I've been using Helix for very short time, and I do like the current completion behavior. Normally, I just press Enter on a selection whenever I need to auto-import libraries in languages such as C++ or Go. Other than that pressing Tab to cycle through is enough to autocomplete for me (just like in Neovim). I wish however that I could 'unmap' Enter for accepting autocompletions and map it to something like <C-L>. I wonder if this is possible at the moment?

[pascalkuthe]

We actually went a different direction here with #6594. Enter is not special anymore in the comolrtuon menu at all. There are two states for the complrtuon menu. When there completion menu is initially opened there is ni selection. If you hit any key you just keep typing (and the completion menu will filter automatically). Hitting enter will closethe completion menu simply because completion items don't co twins newlines.

Once you hit tab the first completion item is selected. Selecting a completion always applys that completion. You cab switch which item is selected but at this point the completion is applied. If you press any ken (besides tab and S-tab and related aliases) the completion menu will be closed.

Enter is again not special here. Once you have selected a completion item it is always applied. The only way to csncek a completion once you have selected an completion item is with c-c.

I thinj the completion keymap is now in a pretty good place. #8021 will fix the last inconsistencies. There will always be an element of personal preference for these keymaos. These should be covered by #5505