New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove timeout for $host.UI prompts #242

Closed
gerane opened this Issue May 22, 2016 · 13 comments

Comments

Projects
None yet
3 participants
@gerane
Copy link
Contributor

gerane commented May 22, 2016

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

This comment has been minimized.

Copy link
Collaborator

daviwil commented May 22, 2016

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.

@daviwil daviwil changed the title Enhancement: Increase timeout for PromptForChoice Increase timeout for $host.UI prompts May 22, 2016

@daviwil daviwil modified the milestones: Backlog, 0.6.2 May 22, 2016

@rkeithhill

This comment has been minimized.

Copy link
Collaborator

rkeithhill commented May 22, 2016

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

This comment has been minimized.

Copy link
Collaborator

daviwil commented May 22, 2016

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

This comment has been minimized.

Copy link
Collaborator

rkeithhill commented May 22, 2016

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

This comment has been minimized.

Copy link
Collaborator

daviwil commented May 22, 2016

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

This comment has been minimized.

Copy link
Contributor

gerane commented May 22, 2016

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

On Sun, May 22, 2016, 2:26 PM David Wilson notifications@github.com 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

This comment has been minimized.

Copy link
Contributor

gerane commented Jun 20, 2016

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 daviwil modified the milestones: 0.7.0, 0.6.2 Jun 20, 2016

@daviwil

This comment has been minimized.

Copy link
Collaborator

daviwil commented Jun 20, 2016

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

@daviwil daviwil modified the milestones: 0.7.0, 0.8.0 Sep 2, 2016

@daviwil

This comment has been minimized.

Copy link
Collaborator

daviwil commented Sep 8, 2016

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.

@daviwil daviwil modified the milestones: 0.7.3, 0.8.0 Sep 8, 2016

@gerane

This comment has been minimized.

Copy link
Contributor

gerane commented Sep 10, 2016

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 notifications@github.com 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 daviwil modified the milestones: 0.7.3, 0.8.0 Nov 29, 2016

@daviwil

This comment has been minimized.

Copy link
Collaborator

daviwil commented Dec 8, 2016

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

@daviwil daviwil changed the title Increase timeout for $host.UI prompts Remove timeout for $host.UI prompts Dec 8, 2016

@rkeithhill

This comment has been minimized.

Copy link
Collaborator

rkeithhill commented Dec 8, 2016

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

This comment has been minimized.

Copy link
Collaborator

daviwil commented Dec 8, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment