Open connor4312 opened 4 years ago
Overall makes sense, though I do have to say that users did not request this thus far because the debug console has much more horizontal space than the other debug views.
Agree with you if the UI does the truncation than no debug adapter changes are needed. I believe I would be open to a PR which does this if we agree to do it on the UI side. Since we use a tree for rendering in the debu console each element can be rendered however we want, which means we can show buttons inline etc In case we deicde to do it this way and somebody wants to do a PR I would be happy to provide code pointers. For now assigning to On Deck because I do not want the bot jumping in and assiging to backlog candidates.
I definitely want this -- too many times, I find myself searching through large arrays and just wanted to output it as a searchable string and the truncation is very frustrating. Honestly, I would even be happy with a setting that would turn off the truncation altogether.
preferably I would like to have have the possibility to not truncate it at all. In my opinion a debugger is supposed to show me the raw data, not do some fancy stuff and obfuscate the informations that I want to have.
Not truncating at all is not a good experience. If dealing with large amount of data it is easy to echo a string/buffer which is hundreds or thousand of MB, which which likely to crash or render the UI inoperable if displayed in the console.
While that could be happen, the truncation today is no where close to that level -- I feel like there is a lot of ground between today's truncation and hundreds/thousands of MBs
Ideally a debugging tool shouldn't get in the way of debugging. There are plenty of editors better suited to explore (for example) JSON output and I'm currently unable to export from the Debug console to these other tools. It's scary there isn't even a setting for this.
If anyone's interested in a terrible workaround I've needed to sprinkle code like this to directly write things I want to output to the file system :( Sadly this doesn't seem to work when for example paused on a line while debugging
fs.writeFile('c:\\temp\\test.txt', serialisedResults, (error: any) => {
console.log(error);
});
@Azim-Palmer you can run copy(serialisedResults)
to copy the untruncated value to your clipboard
Potentially related on Stack Overflow (I'm not completely sure yet): How to fix debug console cutting string in visual studio code (flutter)
+1
+1
People, please stop making comments that just consist of "+1" and similar. Read the rules in https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions. If you want to say "+1", give the first comment in this issue ticket a thumbs up. That's what the maintainers look at to guide what they prioritize. You writing "+1" comments just spams the inboxes of people who want to get pings about actual meaningful discussion or progress related to the issue.
Overall makes sense, though I do have to say that users did not request this thus far because the debug console has much more horizontal space than the other debug views.
I'm finding that variables logged in the Debug Console don't wrap, or permit horizontal scrolling, and results from right click > Copy and Copy All are truncated.
Some years later, there are several SO questions looking for this:
you can run
copy(serialisedResults)
to copy the untruncated value to your clipboard
This is the only workaround I've found for my projects 🙏
In js-debug, we truncate large data inside the debug adapter before giving back to the UI. However, this means that if the user logs a very large string, they have no way to view it. The Chrome devtools solve this by adding a "copy" and "show all" button to very large strings.
We don't currently have a way to show buttons in the output. I believe the just having a "copy" button in the UI is sufficient. An approach for this is to use the
evaluateName
in the output'svariablesReference
with anevaluate
call, in theclipboard
context if supported. It's notable that the UI can use this even for values that aren't truncated to allow the user to copy complex expressions.The question of who does the truncation is orthogonal to the ability to copy. If the debug adapter continues to do the truncation, then it should have a DAP flag to hint to the UI that the value can be expanded (using the presence of an
evaluateName
alone would prevent thatgeneralized copy functionality).If the UI does the truncation, it means more traffic over the protocol, and it might also be tricky to figure out how to show a truncated state for complex objects. But then the UI can also implement "show all" without any debug adapter changes. Overall I think UI-side truncation is preferable.
cc @isidorn @weinand @roblourens