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
{{ message }}
Repository navigation
IFeedbackProvider can't work against native commands on non-zero exit code #18852
The current design of IFeedbackProvider only works against an ErrorRecord. Unless $PSNativeCommandUseErrorActionPreference is $true, no ErrorRecord is created if a native command exists with a non-zero exit code. For example, I can't build a feedback provider for the git command.
Perhaps FeedbackProviders should be registered with a Kind specifying when it should be enacted? I don't know if there will be other cases other than ErrorRecord and non-zero exit code.
Another use case would be for codex, copilot, chatgpt, etc.. integration where I can type a comment:
# get process using the most cpu
and after hitting enter, it could call a feedback provider that can generate a prediction based on the result of the AI result.
In this case, it's not any error condition. I don't think we want to invoke FeedbackProviders on every successful call, so maybe just special case comments?
We need to solve the problem of being able to get native command output when standalone to make some of this work. In the git case, need the stderr output to help build the suggestion.
It may also make sense to have FeedbackProviders register for specific types of events so they aren't called and each needs to check if they should do processing.
For the use case for codex, copilot, chatgpt and etc., comparing with typing a comment and then hitting enter to trigger, I think the user experience will be much better with hitting a PSReadLine key-binding to trigger (basically, having all handled within the PSReadLine). We can easily do more within PSReadLine, such as having a spinning sign indicating it's thinking.
Also, hitting enter to trigger means it has to jump multiple loops, likely "host -> feedback provider -> PSReadLine -> predictor -> PSReadLine". This workflow is fine if the predictor can get more information from the feedback provider, such as the error messages (and the stderr message from native command in future), but for this particular use case, feedback provider doesn't offer additional information -- the comment is already available within PSReadLine.
Activity
SteveL-MSFT commentedon Dec 27, 2022
Another use case would be for codex, copilot, chatgpt, etc.. integration where I can type a comment:
# get process using the most cpuand after hitting enter, it could call a feedback provider that can generate a prediction based on the result of the AI result.
In this case, it's not any error condition. I don't think we want to invoke FeedbackProviders on every successful call, so maybe just special case comments?
SteveL-MSFT commentedon Dec 28, 2022
We need to solve the problem of being able to get native command output when standalone to make some of this work. In the
gitcase, need the stderr output to help build the suggestion.It may also make sense to have FeedbackProviders register for specific types of events so they aren't called and each needs to check if they should do processing.
daxian-dbw commentedon Jan 4, 2023
For the use case for codex, copilot, chatgpt and etc., comparing with typing a comment and then hitting enter to trigger, I think the user experience will be much better with hitting a PSReadLine key-binding to trigger (basically, having all handled within the PSReadLine). We can easily do more within PSReadLine, such as having a spinning sign indicating it's thinking.
Also, hitting enter to trigger means it has to jump multiple loops, likely "host -> feedback provider -> PSReadLine -> predictor -> PSReadLine". This workflow is fine if the predictor can get more information from the feedback provider, such as the error messages (and the stderr message from native command in future), but for this particular use case, feedback provider doesn't offer additional information -- the comment is already available within PSReadLine.
microsoft-github-policy-service commentedon Nov 15, 2023
microsoft-github-policy-service commentedon Nov 15, 2023
microsoft-github-policy-service commentedon Nov 15, 2023
microsoft-github-policy-service commentedon Nov 22, 2023