"Set-PSReadlineOption -EditMode vi" breaks Ctrl+r / bck-i-search

[davetapley]

Environment

PS version: 5.1.19041.906
PSReadline version: 2.0.1
os: 10.0.19041.1 (WinBuild.160101.0800)
PS file version: 10.0.19041.1 (WinBuild.160101.0800)
HostName: ConsoleHost
BufferWidth: 120
BufferHeight: 3000

Exception report

N/A

Steps to reproduce

1. Run Set-PSReadlineOption -EditMode vi
2. Press Ctrl + r
3. Enter string occurring in previously entered command
4. Press Ctrl + r a second time

Expected behavior

bck-i-search: appears and subsequent Ctrl + r scroll through earlier matches.

Actual behavior

find: appears and subsequent Ctrl + r do nothing

Example:

Windows.PowerShell.2021-05-13.11-09-55.mp4

[davetapley]

Difference is explained by:

PSReadLine/PSReadLine/KeyBindings.cs

Lines 208 to 209 in dc38b45

	{ Keys.CtrlR, MakeKeyHandler(ReverseSearchHistory, "ReverseSearchHistory") },
	{ Keys.CtrlS, MakeKeyHandler(ForwardSearchHistory, "ForwardSearchHistory") },

vs

PSReadLine/PSReadLine/KeyBindings.vi.cs

Lines 89 to 90 in dc38b45

	{ Keys.CtrlR, MakeKeyHandler(ViSearchHistoryBackward,"ViSearchHistoryBackward") },
	{ Keys.CtrlS, MakeKeyHandler(SearchForward, "SearchForward") },

---

Implemented by:

PSReadLine/PSReadLine/History.cs

Lines 970 to 973 in dc38b45

	public static void ReverseSearchHistory(ConsoleKeyInfo? key = null, object arg = null)
	{
	_singleton.InteractiveHistorySearch(-1);
	}

vs

PSReadLine/PSReadLine/ReadLine.vi.cs

Lines 934 to 941 in dc38b45

	/// <summary>
	/// Prompts for a search string and initiates search upon AcceptLine.
	/// </summary>
	public static void ViSearchHistoryBackward(ConsoleKeyInfo? key = null, object arg = null)
	{
	_singleton.SaveCurrentLine();
	_singleton.StartSearch(backward: true);
	}

---

Skimming the history it seems like it's been this way for a long time, but I honesty can't think of a use case where ViSearchHistoryBackward would be preferable to ReverseSearchHistory?

In any case it's already also bound to / in command mode:

PSReadLine/PSReadLine/KeyBindings.vi.cs

Line 204 in dc38b45

{ Keys.Slash, MakeKeyHandler(ViSearchHistoryBackward, "ViSearchHistoryBackward") },

[daxian-dbw]

@lzybkr The code change history shows that the interactive history search feature (fwd-i-search: and bck-i-search:) was add in January 2014, while the ViStartSearchBackward (find:) was added in March 2014, 2 months after the interactive history search feature was enabled. Any reason why the VI mode choose to use a different backward history searching UX? Is it OK to use the same interactive search function ReverseSearchHistory/ForwardSearchHistory for the VI mode? (the same interactive search is used in both Windows mode and Emacs mode).

[lzybkr]

The guiding principle at the time was to emulate GNU readline - with few intentional exceptions.

So when this work was implemented, I think it did emulate vi mode in bash.

I don't think there's been any real effort to track changes to GNU readline, but if today vi mode in bash works just like emacs mode, maybe it does make sense to change PSReadLine too.

[daxian-dbw]

I just tried the bash vi mode (set -o vi), and ctrl+r works just like the emacs mode ((reverse-i-search) appears). I guess it's fine then to replace the find: in PowerShell with the same interactive history searching as in Windows and Emacs modes. (Especially, the existing ViSearchHistoryBackward and SearchForward functionalities are already available via the / and ? shortcuts)