-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Add ability to read outputChannel text. #65108
Comments
There will be a document in the |
Totally agree, but that only happens if your log has been viewed recently and from what I've seen it also doesn't have a clear identifier in order to associate it to the channel so you could be getting a random log outputs content. |
Yeah... We have optimised this recently because sync'ing output channels has caused quite some load |
Having this will really benefit the C# extension as for each issue we have to ask the users to upload the output from the omnisharp and the C# channel. It adds to a step in the loop and many times new users dont understand how to do it. |
@sandy081 Would you guys be open to a pull request for the same? |
Its the same step for us that we ask users to provide logs. We ask in following way.
Why not doing the same?
|
For e2e testing, I'm getting the output channel by first opening it (in the test), and then getting it by name. ("extension-output-#5"). The name is troubling, as it seems the extension's name for the output channel "XYZ" is not being used, but instead that generic one "extension-output-#5". If the name could just match up with the choice, or perhaps something such as -output-. |
Also would really like to see this feature for the PowerShell extension for the same reason as @akshita31 mentioned. Having to ask the user to go to the Output Windows (we have 2 of them, one client, one server) and copy the content is an extra step. Especially since a small percentage of folks actually read the issue templates, this feature would save us a lot of back-and-forth time with the user who's having trouble. |
I attempted to script out:
unfortunately, |
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation. Happy Coding! |
Since this is an extensibility feature request, I find it hard to believe that this will get the required likes to not be closed. Please consider not doing that... This would be really useful and the lack of this feature already means I have to ask the user to follow more steps thus delaying my ability to diagnose issues that customers have. |
This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation. Happy Coding |
Pls no |
Out of curiosity the 20 community upvote limit also applies to developer extension APIs? |
It appears so. |
🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation. Happy Coding! |
Reading from an output channel would be excellent. My use case is for walkthroughs. I'd like to read from the output channel to trigger contexts for my walkthrough. E.g. if one step of the walkthrough is the print
|
We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider. If you wonder what we are up to, please see our roadmap and issue reporting guidelines. Thanks for your understanding, and happy coding! |
Ping @sandy081 and @connor4312 This might also be helpful for the debug feature of testing API. To debug, the only way should be to use VSCode's debug configuration, which might be another extension. An example is Rust, the debug extension could be LLDBCode, but the extension which knows rust is Rust-Analyzer. The rust-analyzer creates a debug config and then give control to LLDBCode, then, there is no way to get the output from LLDBCode(in fact it's from cargo, but I think there is no way to capture output from cargo directly). The status of debugging is lost. A hack way might be to use a wrapper, LLDB starts the wrapper and the wrapper starts the real program. Then it's possible to use some IPC ways then to pass the output. If this feature is implemented, life would be much easier. |
I believe this is what #6208 was asking but I disagree that it was a duplicate of the linked issue.
Basically, I'm building an issue reporter that captures log output to make filing issues easier for my extension. For my own logger this is easy because I can just save the data that should have been logged to a variable. However, my extension relies on OmniSharp and they have their own log. It'd be valuable to capture that as well.
The text was updated successfully, but these errors were encountered: