Override input handling in the SelectPrompt

[abpiskunov]

We would like to add extra keys handling for Esc or Ctrl+C in our SelectPrompt. We were trying to clone its implementation and just create AdvancedSelectPrompt however all related contracts are internal (IListPromptStrategy etc).

Is it possible to make those contracts public or add some virtual methods to be overridden in the SelectPrompt (and other ones too)?

[ddirty830]

@patriksvensson
Would you be open to my making some of the ListPrompt interfaces public instead of internal? It wouldn't break things, but would allow for more customization.

The interfaces/classes I'm thinking:

• IListPromptStrategy
• ListPromptInputResult
• ListPromptItem
• ListPromptState

IListPromptStrategy is the goal, but the others come along for the ride.

[patriksvensson]

@ddirty830 These classes were never meant for public extensibility, and I'm reluctant to open them up because of this due to the increased support burden of doing so. As you said, "others came along for the ride". I would need to look at the code and think about what this would mean for the project.

@spectreconsole/maintainers What do you think?

[FrankRay78]

I'm not familiar with IListPromptStrategy and associated interfaces, so I can't comment one way or the other. However, I am now very close to submitting a PR to publically expose the help writer, both in terms of public interfaces that can be implemented, and also the default help writer class (should someone want to override and extend the base behaviour in a custom writer). Importantly, other internal implementation remains internal and sealed to spectre.console. Perhaps the work done in this PR may inform the discussion/decisions here.

[ddirty830]

Opening up the interfaces could lead to solutions to #711 as well, because people could then tweak it themselves. For example: implement their own HandleInput to process Escape, clear selections, and then return ListPromptInputResult.Submit. Since they implemented it themselves, they would know to handle the "empty" result case as cancel.

Another use could be: I have a list of 50 alphabetical options. I want to type 'N' to go to the first item in the list (kind of like Windows Explorer to skip to a file), so I can then select/deselect. Without being able to handle key input, it's impossible.

The other route (as the code stands) for both, would be to duplicate all of the ListPrompt code in their own projects, which is then license/maintenance trouble.

I'm not sure if the best route is virtual methods vs public interfaces/classes (but still sealed). Virtual methods in some scenarios would still require public'ing interfaces.

[abpiskunov]

FYI the reason I filed this suggestion is that we did not find alternative approaches. I did try to implement a new SelectPrompt from scratch by copying some original logic, however it is using so much internal stuff that I had to copy too much code and stopped. The only option so far is fork the repo , make it private and do all changes we need. Which I believe is not really the best approach...

[FrankRay78]

FYI. PR now submitted, if you want a peek at making the help writer injectable and extensible: #1259