Allow Overwrite of Stacktrace with SupportsDelayedStackTraceLoading
@connor4312 已经在做这个了。
开始于 2024年10月12日。
评估
这个 Issue 还没有评估数据。
描述
I have a situation where calculating my stacktrace is expensive (takes 300ms-800ms in PowerShell for "reasons").
Editors such as vscode will not display where they are stopped until they receive the first stackTrace frame, then they will background the remainder stacktrace fetch if SupportsDelayedStackTraceLoading is specified. Because of this, stepping in the PowerShell debug adapter feels "slow" as the editor will not respond until I can give it at least one stack trace.
I can send it a "dummy" breakpoint frame immediately that is 90% there with id: 0 in order to get the editor UI to respond quickly, but if the editor requests the next stackTrace by startFrame at 1, if I "spuriously" supply it again via id:0 it still gets appended to the call stack list rather than replace what is in the call stack.
Before I can ask in vscode to change this behavior, it should be less ambiguous in the spec, so either a statement that says subsequent stacktrace requests with the same ID should overwrite the existing stacktraces if spuriously received outside the requested range, or allow an additional method before stacktrace (or additional property as part of stopped event) that allows specifying the breakpoint location so the editor can immediately place its pointer there while backgrounding for further callstack/stacktrace info.
Thanks!
- 主要语言
- HTML
- 星标
- 1.8k
- 派生
- 173
- 平均合并
- 7 天 7 小时
- 30 天内合并 PR
- 2
环境准备
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
microsoft/debug-adapter-protocol 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
-
难度 5/5 一周以上 新手友好度 35/100
microsoft/debug-adapter-protocol#633 · 1 条评论 ·
-
难度 4/5 3-5 天 新手友好度 42/100
-
难度 5/5 一周以上 新手友好度 35/100
microsoft/debug-adapter-protocol#599 · 8 个 reaction ·
-
under-discussion
难度 2/5 1-3 小时 新手友好度 48/100
microsoft/debug-adapter-protocol#596 · 9 条评论 ·