Adding VI edit mode, along with unit tests.

[srdubya]

I've been through my list of functionality and everything is working with the exception of 'G' -- move to the specified history line.

[lzybkr]

Just a general comment - Get-PSReadlineKeyHandler output needs some help for vi-mode. As a quick example, I did not expect to see all History functions unbound.

Get-PSReadlineKeyHandler | ? { $_.Function -like '*History*' }

Maybe we add a column to the output saying which keys are bound in which mode.

[twsouthwick]

There hasn't been any movement on this PR for 5 months - any work still being done on it? I'd like to see the VI mode available :)

[lzybkr]

Indeed, there hasn't been any movement and I apologize for that. Thanks for the poke. I'll explain where we're at.

I work on the PowerShell team, so I'm in a unique position. PSReadline could be included in a future version of PowerShell with very little hassle. All of the core (non build script/test) code (modulo 53714c0 and 5e6ec28) is written by a Microsoft employee (mostly me, but there are a few contributions from one other MS employee).

If I accept this pull request, then we are in a different position with regard to including PSReadline in future versions of PowerShell.

A year ago, I would have said that contributions from non-Microsoft employees to Windows can never happen, and probably just have accepted this pull request. But the company is changing and accepting non-Microsoft employee contributions to a project like PSReadline and including that code in Windows can actually be seriously considered now.

So we've been exploring this idea. It hasn't been a high priority thing, but we (the PowerShell team) started talking with some of the folks that would need to approve a decision like this, so there has been some progress internally but it's been slow.

The other "issue" - this project is a free time project for me and summer free time is spent outdoors as much as possible because, well, Seattle summers are amazing, the rest of year, not so much. So I haven't spent the time I need to on Steve's work to give it my stamp of approval. I have very high standards, but it's a lot of code and I need time to ensure it will meet peoples expectations. Steve was very cooperative in making changes I had asked of him earlier, hopefully he'll still have time when I do get around to finishing reviewing the pull request.

One last thing - there are mixed feelings around including PSReadline in PowerShell. Some folks really appreciate frequent releases for bug fixes and new features and the open development on GitHub, others would really like to not have to tell folks to install something extra to get a usable shell :). I will say that if we do include PSReadline in PowerShell, I expect this project will be maintained because, well, frequent releases are a good thing.

[lzybkr]

One more thing (in a different comment so it's not buried in my long comment)

I like data - if anyone is using Steve's fork for vi-mode, let me know how it's working for you. The code looked pretty good, but vi emulation is tricky.

[rkeithhill]

I'm of two minds about including PSReadline in PowerShell. On the one hand, I think that would be great in terms of getting folks to just start using PowerShell as a CMD replacement to run utility exes. But on the other hand, I worry that the ability to fix PSReadline bugs and add features could slow to a crawl. That is, unless we could easily replace the "built-in" version of PSReadline with the latest & greatest off of this repo which seems totally doable. If so, then I'm all for including it in PowerShell.

Perhaps I'm overly paranoid based on the previous experience of asking for PowerShell to be included in Windows in order to get universal availability. We got what we asked for with Windows 7 but then suffered with a three year gap until the next release of Windows. We couldn't even get really annoying bugs fixed for three years. :-(

[srdubya]

I too have been busy outdoors during the summer months. I plan to get back at it once it's too nasty outside to ride.

[gwojan]

I would love to see PSReadLine shipped with PowerShell but only if you can continue to maintain it out of band with PowerShell. It should be possible with all the new module support coming in v5 right? ;-) NuGet is shipped with Visual Studio now but can be upgraded with the latest community release. Why can't something like this be done with PowerShell/PSReadLine?

I started using PSReadLine with the promise of Vi emulation somewhere on the horizon. Even though I haven't used the Vi fork PSReadLine is now a must have. Jason, please keep up the awesome work. :D

BTW, I'm still keeping my fingers crossed for Vi emulation to included.

[Kethku]

Is there any way to use this pull request in windows 10 which now comes with psreadline? I can't seem to install the module after I built it, and I can't uninstall the version that comes with windows now.

[Kethku]

I got it working on my win 7 machine and I love it, I wish I could add it everywhere

[lzybkr]

@Devagamster - You can

• Delete the version in $env:ProgramFiles\WindowsPowerShell\Modules\PSReadline\1.1 (must be admin)
• Change $env:PSModulePath (in the registry probably) so that a location you control comes before $env:ProgramFiles\WindowsPowerShell\Modules, and install it in that location.
• Install in $env:ProgramFiles\WindowsPowerShell\Modules\PSReadline\1.2 (a higher version is preferred).

[Kethku]

Thank you for the quick response! As PSReadline potentially diverges on github from the one that ships with windows 10, it would make sense to document ways to use a more bleeding edge version like you suggest above. If you like I could create a pull request adding this to the readme?

Unless I completely missed it haha

[lzybkr]

@Devagamster - sure. Be sure to try out what you put in the readme to make sure it works, I may have suggested something that doesn't actually work.

[Kethku]

Will do