You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had some ideas about how to flesh out some of the extensibility APIs. The original motivation was to allow context specific key handler assignments in menus like MenuComplete. As I was looking into how PSRL might be changed to allow this, I came up with some ideas that would make extending PSRL a lot easier in general.
I do realize that the changes I'm about to propose would be unavoidably less performant, but I'd like to hear your thoughts. Here's a rough draft of what I have in mind.
Stories
As a user I want to
Customize input handling of menus created by key handlers (both default and custom)
As a writer of custom key handlers I want to
Temporarily take over a default action when I present a menu, regardless of what key that action is assigned to
Allow PSRL to handle string manipulation of a custom input buffer
Bind keys to "dispatch" codes instead of delegates
Assigning keys
// Enum-like for default commands, borrowing a little from the// design of System.Reflection.Emit.OpCodes.classKeyHandlerCommand{// Default dispatch codesstaticListMoveDown{get;}staticListMoveUp{get;}staticAccept{get;}staticSearchHistoryBackward{get;}
...// Registering custom dispatch codesstaticKeyHandlerCommandRegisterCustomCommand(stringdispatchCode,Action<ConsoleKeyInfo?,object>defaultHandler);staticKeyHandlerCommandGetCustomCommand(stringdispatchCode);// Instance propertiesstringDispatchCode{get;}Action<ConsoleKeyInfo?,object>DefaultHandler{get;}}
The idea here is that a key handler that implements a menu would take over a command using this API and dispose of the return value to relinquish control back to PSRL. If this was a public API it would allow external custom menus to use existing key bindings.
Nested input buffers
This one in particular might be a long shot, but the ability tap into PSRL's string manipulation would greatly reduce the barrier of entry for custom menu creators.
Nothing you've proposed concerns me from a performance perspective.
If you are only proposing internal implementation details, then my primary concern is simply justifying the additional complexity. I briefly considered supporting custom bindings for the nested input loops in history search but decided the baked in experience didn't need customization.
So the question is - how much customization do people need, or can you simply bake in the experience to PSReadLine directly?
As for nested editing - that seems useful. As part of that, I'm thinking your nested editing scenarios are not a PowerShell command line, so things like coloring should be disabled and completion highly customized (return only files/directories?)
I'm happy to have a more interactive chat as well - ping me on gitter if you'd like.
Activity
lzybkr commentedon Aug 27, 2018
Nothing you've proposed concerns me from a performance perspective.
If you are only proposing internal implementation details, then my primary concern is simply justifying the additional complexity. I briefly considered supporting custom bindings for the nested input loops in history search but decided the baked in experience didn't need customization.
So the question is - how much customization do people need, or can you simply bake in the experience to PSReadLine directly?
As for nested editing - that seems useful. As part of that, I'm thinking your nested editing scenarios are not a PowerShell command line, so things like coloring should be disabled and completion highly customized (return only files/directories?)
I'm happy to have a more interactive chat as well - ping me on gitter if you'd like.