Closed NTaylorMullen closed 1 year ago
There will be a document in the vscode.workspace.textDocuments
which has your contents but it's not linked to the channel.
There will be a document in the
vscode.workspace.textDocuments
which has your contents but it's not linked to the channel.
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.
Totally agree, but that only happens if your log has been viewed recently
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.
Please provide us logs from following location
F1 > View: Open View > Log(Shared)
Why not doing the same?
F1 > View: Open View > C#
?
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
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:
vscode.workspace.textDocuments where languageId === "Log"
)unfortunately, myLanguageClient.outputChannel.show()
doesn't seem to work - the Output pane nor the language client's specific output window opened.
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.
Pls no
Out of curiosity the 20 community upvote limit also applies to developer extension APIs?
It appears so.
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 Hello world
to standard out (which in my case, then writes to its own output channel), I'd like to be able to capture that.
const outputChannel = vscode.window.getOutputChannel(`IBM i Output`); //This channel is from another extension
outputChannel.on(`append`, (content) => {
if (content.includes(`Hello world`)) {
vscode.commands.executeCommand(`setContext`, `code-for-ibmi-walkthroughs:helloworld`, true);
}
});
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.