Remove timeout for $host.UI prompts

[gerane]

Currently when using an editor command that waits for user input the timeout is very short. Often times it will silently cancel in the background while you are still working on your selection. This can make the experience of using the Editor Commands frustrating when dealing with long lists or long names.

[daviwil]

Yep, that's coming from here: https://github.com/PowerShell/PowerShellEditorServices/blob/master/src/PowerShellEditorServices/Session/SessionPSHostUserInterface.cs#L326

Currently the timeout is 15 seconds but it seems that I need to increase that to 45 or 60.

[rkeithhill]

Does there have to be a timeout? The user can always stop a debug session that is waiting for a response. Not sure about the editor session. But a read-host prompt from the command line will wait for minutes at least and I suspect - indefinitely.

[daviwil]

The thing I'm concerned about is if a prompt shows up in the language service and the user doesn't realize it and then wonders why no language features are working anymore. I could just push the timeout to something really high like 2-5 minutes if it makes more sense?

[rkeithhill]

A few minutes would definitely be better than 15 seconds. But I don't think it would be that uncommon for someone to get distracted when answering a series of Plaster prompts - then come back after the distraction to find that the prompt timed out. What happens then? Is it obvious to the user what happened? Does the command stop in its tracks? Starting over isn't a huge deal but if it somehow proceeds with incomplete info - that wouldn't be good.

[daviwil]

Yeah, I've thought about that too. I write a message to the output pane stating that the prompt timed out, so at least the user knows that it happened for that reason. However, it could be a problem if we just cancel the pipeline if the user didn't want that to happen. I'm open to taking it out entirely if you think it's the right thing to do.

[gerane]

It seemed like it was way less than 15 seconds to me.

On Sun, May 22, 2016, 2:26 PM David Wilson [email protected] wrote:

Yeah, I've thought about that too. I write a message to the output pane
stating that the prompt timed out, so at least the user knows that it
happened for that reason. However, it could be a problem if we just cancel
the pipeline if the user didn't want that to happen. I'm open to taking it
out entirely if you think it's the right thing to do.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#242 (comment)

[gerane]

Is this making it into the next release @daviwil ? I can't really use a lot of my editor commands due to it timing out faster than I can type my answer or find my selection. Especially if it is a response that I have to stop for a second to think about, It usually always times out on anything that takes more than a couple seconds for the selection.

[daviwil]

Yep, it's a simple change to a constant value, I'll get it in :)

[daviwil]

Apparently this got lost in the noise of what was happening over the last few months ;) I'm gonna put out an 0.7.3 release in the next few days, I'll include this change with that.

[gerane]

I just thought about this today and was going to ask you about it lol.

On Thu, Sep 8, 2016, 10:01 AM David Wilson [email protected] wrote:

Apparently this got lost in the noise of what was happening over the last
few months ;) I'm gonna put out an 0.7.3 release in the next few days, I'll
include this change with that.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#242 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGWoQNbNEy3VLfjbTZ38QwFGoAobsW_bks5qoCNggaJpZM4IkBhC
.

[daviwil]

I'm taking out this timeout entirely for 0.8.0 :) Fix incoming.

[rkeithhill]

I wonder if you could display some sort of "waiting for user input" indicator in the PowerShell area of the status bar. In the PowerShell console it is a bit more obvious when a script is stopped waiting on input. Less so in the debug console.

[daviwil]

That's an interesting idea, having a running/waiting indicator. I think Trevor had asked for a running indicator in the past. Actually, I just merged a change that Doug made that allows us to send status bar messages back to the editor so maybe I can use that.