Cool 👍 Does it work the same with

• tab/shift-tab,
• ↓/↑ and
• ctrl-n/ctrl-p?

@laughedelic: Of course this is independent of the particular key - this modifies the pager's movement function, so any binding that calls any bind function that then moves the pager selection with one of the affected directions will be affected.

↓/↑ and
ctrl-n/ctrl-p?

These are bound to "up-or-search"/"down-or-search" respectively, which are wrapper functions that call the "up-line"/"down-line" bind functions. So yes, they are fully affected.

tab/shift-tab

These are bound to "complete" and "complete-and-search", which call the pager movement with "direction_next"/"direction_prev". They aren't affected, but there's nothing particularly wrong with them as far as I'm aware.

OK. Thanks for clarifying!

This needs some adjustment to the tests - I didn't notice that we had some in src/fish_tests.cpp (I always forget about that, and I don't think ninja updated that correctly).

The first failure is moving "west". Let's say the pager looks like this:

[1] 2  3  4  5
6   7  8  9  A
B   C  D  E

(with [] denoting the cursor position on the 1)

and move "west"? Currently, this goes to 5, while moving "east" then goes to 6 (i.e. getting back to 1 from 5 requires either going east and then up or going west 4 times). With this, it goes to E instead (i.e. the last filled column in the last row). Moving east then returns one to 1.

So moving east or west just iterates in (western) reading-order - go through all the columns, then go to the next row and the starting column. Whereas now it does that, except it gets stuck in the last row.

This makes it so that east/west reverse each other, which is a nice property. On the other hand, that "column memory" feature is now gone as far as I can tell.

Merged as 1307991..12c249a.

I originally used github's conflict resolution feature, but that adds a merge commit, which is kinda superfluous when I could just directly change the changelog commit to resolve the commit.