PowerShell
Make completer menus reusable
Regarding the existing MenuComplete function (Ctrl+Space) and the new "F2" history menu, a couple of requests:
- Can we expose these menus as commands to make them usable by other modules as a way to prompt for input? It's always frustrating for PowerShell script authors that
$Host.UI.PromptForChoiceis so hard to use ... - Can we offer an command to turn one of these menus "on by default" to provide a slightly more intellisense-like feel to the prompt? Most people won't want that all the time, but it could be super useful on a temporary basis (particularly for learning new modules, since the
MenuCompletecompleter shows the full syntax block for commands):
For your comment (1), MenuComplete is part of PSReadLine, not the host. That means it won't be generally available to all applications that hosts PowerShell and thus won't be reliable for a module to use. Are you suggesting to move MenuComplete to PowerShell host?
More sounds like the ask is to provide a PSReadLine cmdlet that allows users to invoke a MenuComplete (for F2) action for more general purposes, rather than just being a PSReadLine builtin functionality that is otherwise entirely inaccessible.
Right, but that depends on the PSReadLine module to be available, which may not be the case for a custom PowerShell host. So a module cannot use that to replace the $Host.UI.PromptForChoice call because the latter is part of the base type of the host, which is generally available.
For your comment (1),
MenuCompleteis part of PSReadLine, not the host. That means it won't be generally available to all applications that hosts PowerShell and thus won't be reliable for a module to use. Are you suggesting to moveMenuCompleteto PowerShell host?
PowerShell scripts and modules can and do frequently take dependencies on (particular versions of) Powershell modules, but rarely if ever rely on specific versions of the PowerShell host.
I am suggesting that this should be a command available in the PSReadLine module which could be called by other modules or scripts which take a dependency on (a future version of) that module. Modules are versioned, and generally backward compatible (and PSReadLine is, specifically, installable even down to Windows PowerShell), and are in my opinion inherently the right shipping container for most functionality.
Perhaps it'd be better if the UI functionality parts of PSRL is split out into a slightly more general-purpose module that can be used from PS and C# modules? That way, you could take a dependency on the UI portion without necessarily requiring PSRL itself to be loaded, and PSRL would just take that same dependency for the functionality it needs.
I don't think that's necessary, but I wouldn't argue against it. Remember though, that interactive "custom PowerShell hosts" that don't ship and depend on PSReadLine are purely hypothetical in nature.
Came here looking for a solution to have a not-so-ugly menu as provided by PromptForChoice or reimplementing the wheel.
Would be cool if this could be added as either a cmdlet provided by the PSReadline module or if possible, even to the PowerShell host.
