spectre.console

spectre.console copied to clipboard

Is your feature request related to a problem? Please describe. When using prompts in my scenario I have a default option at the top but (for cake build) but user has to press enter to use default when running build with no arguments

Describe the solution you'd like Add an extension to the Prompts - like MulitSelect that would timeout after n seconds and use the defined default value

Describe alternatives you've considered Doing something around Task timeouts and wrapping the prompt in that with a cancelation token? But that throws a Cancellation Exception so need to catch that.. quite ugly

Additional context All provided above really

Thanks for a great library! ❤️

Just some pseudo code really to see what you think. Getting ideas together and learning the code base a bit. If it were to make production code what would it take and does this look like a viable option.

just on side note while learning the code... I am a little bit confused by the async implementation though.. it looks SelectionPrompt is fully synchronous and the only reason it has an async method is to call async Prompt, just because it has an async ReadKey... Is that async readkey helping with the rending somehow in a vital way?

We came up with a working solution yesterday. Our CancellationToken expert made a few tweaks to merge token and some logic.

We then ran into an issue on how to bubble up that a person presses a key to stop the progress bar wrapped around the MultiSelect. Best thing we came up with wiring in an event.

So we thought.. you know.. we can just inherit this class and rewire these things for our own purposes without having to mess around your code and, forking, PR's ..

Why did you seal these classes? 😖😖

@ppumkin The way to run an IPrompt is async/await in nature and needs to support cancellation of reading user input. The T Show(IAnsiConsole console) is the old entry point for people who want to invoke this synchronously. We could probably replace the synchronous method with an extension method, but that would break the ABI.

Unless something is built for extensibility, we seal everything by default, and SelectionPrompt<T> is not built for extensibility. We prefer to bring things into the existing code, and if there is a significant need, create something generic that is made with extensibility in mind.

I have no objection to adding a timeout to prompts, but this would need to be done in a way that's transparent to the user, regardless if they are running it synchronously or asynchronously, and always return a valid value as it does now.

Thanks @patriksvensson So I could make PR if you wanted to and work out exactly how it should fir in with your architecture.

• Set CancelAfter on cancellation token on the Async version
• • Possibly make the cancellation token class level variable with a method to set it or allow the user to pass in a modified cancelation token on the Async method
• Detect CancelAfter
• • Throws an exception so you want to wrap try catches for TaskCanceledException?
• HandleInput - Propagate event from HandleInput back to user somehow. as that should change the CancelAfter on cancellation token if user is passing it in or internally ... Plus allow the user to do something else on the UI - Like stop a progress bar/ count down timer