如何在VS代码API直接实现中处理慢速诊断
直接实现的VS代码扩展程序中的诊断（无语言服务器）在运行时阻止了其他事情（例如完成）。此外，似乎如果在先前的分析完成延迟之前再次触发它们，则将乘以几倍。结果，在复杂的工作空间上，体验可能非常不愉快。
是否有一个扩展名的示例，该扩展名 使用LSP，这很好地处理了这一点，因此，API文档在这一点上非常轻松，而且我没有通过搜索来找到太多信息。或者，有人可以总结一下处理它的广泛策略。同样，问题在于诊断持续时间太长。
进一步的注意：
- 在早期尝试中，我尝试简单地调用每个文档更改事件的诊断，结果非常好，对于小文件来说非常好，但对于大文件而言，灾难性的结果。
- 通过使用计时器来防止诊断快速连续运行，即如果最近启动另一次跑步，则不会运行诊断。在“文档将保存”上强迫运行。
- 简而言之，将诊断功能放在异步功能中，似乎没有改进，但也许没有花费足够的时间来处理它。这应该是必要的吗？我有点认为，API会照顾幕后的同时操作。
The diagnostics in my VS Code extension, implemented directly (no language server), are blocking other things (e.g. completions) while they run. Furthermore, it seems, if they are triggered again before the prior analysis completes the delays are multiplied several-fold. As a result the experience can be very unpleasant on complex workspaces.
Is there a small example of an extension that does not use LSP, and that handles this well, the API documentation is very light on this point, and I don't find much info by searching. Or, can someone give a summary of a broad strategy for dealing with it. Again, the issue is diagnostics are blocking other services for too long.
Further notes:
- In early attempts I tried simply invoking the diagnostics on every document change event, results very nice for small files, but disastrous for large ones.
- Somewhat better results by using a timer to prevent diagnostics from running in rapid succession, i.e., do not run if another run was recently started. A run is forced on "document will save".
- Briefly toyed with putting diagnostics in an asynchronous function, seemingly no improvement, but maybe did not spend enough time working at it. Should this be necessary? I kind of thought the API would take care of concurrent operations behind the scenes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论