@Anthony-Eid @ngauder and I went back and forth on this a little bit. I think the fix is useful, and I'm not sure a better way to factor it, but would love a second opinion from you.

The fix makes sense, the only thing I'm not a fan of is that it's adapter specific. There doesn't seem to be a clean way around that though.

I wonder if there's an arg we can pass into Debugpy to fix this, or if we should submit a PR.

A PR to Debugpy seems sensible @ngauder if you want to take a pass.

Going to merge this in the meantime.

I dug a bit into this and found the code in debugpy that's responsible for generating the str representation: https://github.com/microsoft/debugpy/blob/2801e484ceee299390a037c6a71a6d305c42ba35/src/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_safe_repr.py#L264

From what I can tell, there doesn't seem to be a clean way to fix this on our side since it's inherent to how debugpy (via pydevd) generates safe string representations.

While looking into it, I also noticed another related issue: very long strings are truncated by debugpy. That means when debugging from Zed they won't be copied correctly to the clipboard because the value we receive is already truncated.

Quick demo:

ok = "a" * 2**16
too_long = "a" * 2**16 + "!"

print("breakpoint here")
print(ok)
print(too_long)

In this case, too_long gets truncated in the debugger representation, so copying it won't yield the real value (see also microsoft/debugpy#1204 and microsoft/vscode#73845).

Maybe the proper way to solve this would be to obtain the variable value via a ReadMemory DAP request (or some other mechanism that bypasses the repr) specifically when copying a value to the clipboard rather than relying on the string representation we get for display in the debugger UI. But I'm not very familiar with the best approach here/no expert in this area.