> You can move to the next line in the buffer editor with `k` but to move down to the next line in the file explorer you have to do `ctrl+n`?

I've never used Helix, but this exists in vim too, but it the autocompletion, because in that context hitting k would type k. Makes sense right? I'm guessing hitting k in Helix file explorer has a similar use, maybe searching?

▲

eviks 6 hours ago | parent [-]

Nope, you'd then do Ctrl+K, not N

▲

worksonmine 4 hours ago | parent | next [-]

(Neo)Vim omnifunc? Ctrl+k does nothing in my setup, probably your config or a plugin. Or am I misunderstanding what you mean?

▲

eviks 4 hours ago | parent [-]

Yes, a slight misunderstanding, I only meant that the fact that K types in insert mode doesn't mean you move to Ctrl+N to replicate its functionality, you should still maintain the same position (K)

▲

worksonmine 4 hours ago | parent [-]

Sure, but [n]ext and [p]revious are common in the TUI world and which one makes more sense is debatable. There's decades of history behind the choice and while I prefer j/k I wouldn't call n/p wrong.

▲

eviks 4 hours ago | parent [-]

Yes, it's an very common mistake, there is also decades of history behind fixing it. But the debate here is not j/k vs [n]ew file/[p]rint file, but about the inconsistency of using one logic in navigating lines of text in an editor vs another in navigating lines of text in a file list

> consistent and transferable keybinds

	▲	worksonmine an hour ago \| parent [-]
		I'm pretty sure next and previous are older than new file and print file both of which have little use in this context. You could also see it as navigating lines of text vs navigating results in a list (ie search in less/vim) if you want to be pedantic. In (Neo)Vim <C-j> in insert mode inserts a new line below the current and <C-k> inserts digraphs. N/P are not necessarily inconsistent.

▲

4 hours ago | parent | prev [-]

[deleted]