Fix diagnostic error, improve delay execution of project update

[RimuruChan]

• 修复错误修正保存后不被清除的问题
• 修复保存事件被忽略问题

[RimuruChan]

🤔

[waruqi]

还没时间看

[waruqi]

我试了下，等了一分钟，还是一样，之前老的错误没被清掉。感觉还是可能被漏掉

[RimuruChan]

我试了下，等了一分钟，还是一样，之前老的错误没被清掉。感觉还是可能被漏掉

保存了吗，保存了才会触发更新

[RimuruChan]

我晚点看看，干脆加个锁吧，这样肯定不会同时存在多次检查，也不会频繁触发

[waruqi]

我试了下，等了一分钟，还是一样，之前老的错误没被清掉。感觉还是可能被漏掉

保存了吗，保存了才会触发更新

保存了

[waruqi]

我晚点看看，干脆加个锁吧，这样肯定不会同时存在多次检查，也不会频繁触发

加锁会不会卡。。file updated 有可能瞬间触发 几千次的，其他的都等锁么？然后挨个排队处理完？那这起的 xmake 进程量有点多，尽管不是并行起的，但是会挨个起几千次。。

[waruqi]

我觉得没必要搞这么麻烦，每次去增删。。

每次检测到 file changed 更新，先清空下 问题列表，完整重新添加现有的就行了。。

参考 https://github.com/xmake-io/xmake-vscode/pull/181/files ，不过这个 patch 测下来也有点小问题。。

[waruqi]

https://github.com/xmake-io/xmake-vscode/pull/181 这个 patch 可以，问题列表的更新也解决了，检测延迟我也调整到了 3s 内。。

这里我先 close 了。你可以先测试下，如果有其他问题需要改进，可以再来个新 pr

[RimuruChan]

我晚点看看，干脆加个锁吧，这样肯定不会同时存在多次检查，也不会频繁触发

加锁会不会卡。。file updated 有可能瞬间触发 几千次的，其他的都等锁么？然后挨个排队处理完？那这起的 xmake 进程量有点多，尽管不是并行起的，但是会挨个起几千次。。

加锁不是等待，，是丢进队列，， 队列实际上也就是个flag，就是这次执行完要不要再执行一次而已，， 这样不需要有延迟，也不会不能及时更新

[waruqi]

我晚点看看，干脆加个锁吧，这样肯定不会同时存在多次检查，也不会频繁触发

加锁会不会卡。。file updated 有可能瞬间触发 几千次的，其他的都等锁么？然后挨个排队处理完？那这起的 xmake 进程量有点多，尽管不是并行起的，但是会挨个起几千次。。

加锁不是等待，，是丢进队列，， 队列实际上也就是个flag，就是这次执行完要不要再执行一次而已，， 这样不需要有延迟，也不会不能及时更新

那这个队列有可能很大，得 上千 size，并且后续的排队中的是否要执行 还得处理判断，但是其实每次只要最新的一次 xmake check 结果就行了。。没必要还去排队。。

如果 1s 内触发了 1 千次，不管用最开始那次 还是最后那次 xmake check 。。结果都是一样的，因此人为操作 1s 内不可能再去编辑一次，就要去重了就行。。

目前测下来 刚那个 patch 基本修复了我这遇到的问题

[RimuruChan]

如果 1s 内触发了 1 千次，不管用最开始那次 还是最后那次 xmake check 。。结果都是一样的，因此人为操作 1s 内不可能再去编辑一次，就要去重了就行。。

队列实际上也就是个flag，就是这次执行完要不要再执行一次而已，， 这样不需要有延迟，也不会不能及时更新

延迟+加上这个策略=及时响应且不会刷多次

一共只会执行两次

[RimuruChan]

我晚点看看，干脆加个锁吧，这样肯定不会同时存在多次检查，也不会频繁触发

加锁会不会卡。。file updated 有可能瞬间触发 几千次的，其他的都等锁么？然后挨个排队处理完？那这起的 xmake 进程量有点多，尽管不是并行起的，但是会挨个起几千次。。

加锁不是等待，，是丢进队列，， 队列实际上也就是个flag，就是这次执行完要不要再执行一次而已，， 这样不需要有延迟，也不会不能及时更新

那这个队列有可能很大，得 上千 size，并且后续的排队中的是否要执行 还得处理判断，但是其实每次只要最新的一次 xmake check 结果就行了。。没必要还去排队。。

你现在这个十秒内保存两次，在第二次保存就不会有更新。必须要我等十秒再保存，， 而不是在最后一次更新的延迟几秒后自动执行1次保存

[waruqi]

我晚点看看，干脆加个锁吧，这样肯定不会同时存在多次检查，也不会频繁触发

加锁会不会卡。。file updated 有可能瞬间触发 几千次的，其他的都等锁么？然后挨个排队处理完？那这起的 xmake 进程量有点多，尽管不是并行起的，但是会挨个起几千次。。

加锁不是等待，，是丢进队列，， 队列实际上也就是个flag，就是这次执行完要不要再执行一次而已，， 这样不需要有延迟，也不会不能及时更新

那这个队列有可能很大，得 上千 size，并且后续的排队中的是否要执行 还得处理判断，但是其实每次只要最新的一次 xmake check 结果就行了。。没必要还去排队。。

你现在这个十秒内保存两次，在第二次保存就不会有更新。必须要我等十秒再保存，，

但现在不用锁，好像也没啥问题了。。10s 我已经改成 < 3s 了

[RimuruChan]

但现在不用锁，好像也没啥问题了。。10s 我已经改成 < 3s 了

问题依然存在，。三秒内保存两次就不会更新，非要我等三秒再去保存一次。

而且三秒，如果xmake进程没有退出，一样会堆进程

[waruqi]

但现在不用锁，好像也没啥问题了。。10s 我已经改成 < 3s 了

问题依然存在，。三秒内保存两次就不会更新，非要我等三秒再去保存一次。

这种已经是小概率事件了，毕竟改 xmake.lua 编辑 + 保存，也需要时间的，用户日常改完配置+保存的时间 小于3s 内完成的概率，原本就不大，没必要了，，就算还有用户手速飞快能这么搞，再调整到 <2s 也可以。。再小就真没必要了，概率极低，几乎不影响体验，没必要搞得太复杂。

而且三秒，如果xmake进程没有退出，一样会堆进程

xmake check 不可能 3s 还没退出，又不是 build 。。除非有 bug ，那也是修 xmake

而且 3s xmake check 进程没退出，不管怎么搞都是会堵的

[RimuruChan]

但现在不用锁，好像也没啥问题了。。10s 我已经改成 < 3s 了

问题依然存在，。三秒内保存两次就不会更新，非要我等三秒再去保存一次。

这种已经是小概率事件了，毕竟改 xmake.lua 编辑 + 保存，也需要时间的，用户日常改完配置+保存的时间 小于3s 内完成的概率，原本就不大，没必要了，，就算还有用户手速飞快能这么搞，再调整到 <2s 也可以。。再小就真没必要了，概率极低，几乎不影响体验，没必要搞得太复杂。

而且三秒，如果xmake进程没有退出，一样会堆进程

xmake check 不可能 3s 还没退出，又不是 build 。。除非有 bug ，那也是修 xmake

而且 3s xmake check 进程没退出，不管怎么搞都是会堵的

并非小概率事件，因为没有lsp，我要经常保存来workaround， 不是说改完才会保存的，，改配置期间就会频繁保存验证写的是不是对的，， 因为没有lsp，不然也不至于这样搞，，

保存又不是只有xmake操作，，更新compile commands之类的也是，，

只是加延迟根本治标不治本，体验也差，， 加延迟好歹也是我这种，不会丢保存事件，，等到时间了至少更新一次，不用用户去等然后再保存再更新，，

[RimuruChan]

加上请求队列(size1)之后直接治根，也提升体验，， 我晚点看看怎么实现你再看看吧

[waruqi]

保存又不是只有xmake操作，，更新compile commands之类的也是，，

现在这个问题诊断 还会去解析 compile commands? 我只看到处理 xmake check 么。。这个不就只需要 xmake.lua 么？

并非小概率事件，因为没有lsp，我要经常保存来workaround， 不是说改完才会保存的，，改配置期间就会频繁保存验证写的是不是对的，， 因为没有lsp，不然也不至于这样搞，，

你可以调到 <1s 试试，我感觉也差不多了。。再怎么频繁保存，也不太可能 <1s，我键盘敲几个键 1s 就过去了。

[RimuruChan]

保存又不是只有xmake操作，，更新compile commands之类的也是，，

现在这个问题诊断 还会去解析 compile commands? 我只看到处理 xmake check 么。。这个不就只需要 xmake.lua 么？

https://github.com/xmake-io/xmake-vscode/blob/b3404baae497c0261793bd0d39c636fd21d6cb5a/src/xmake.ts#L279

并非小概率事件，因为没有lsp，我要经常保存来workaround， 不是说改完才会保存的，，改配置期间就会频繁保存验证写的是不是对的，， 因为没有lsp，不然也不至于这样搞，，

你可以调到 <1s 试试，我感觉也差不多了。。再怎么频繁保存，也不太可能 <1s，我键盘敲几个键 1s 就过去了。

。。明明有更好的方案，为什么不用呢，旧方案好在哪呢。。

[waruqi]

this.updateIntellisense();

这么目前也只是根据 xmake.lua 保存触发，没啥区别

。。明明有更好的方案，为什么不用呢，旧方案好在哪呢。。

就看有没有必要，如果新方案改完，跟现在的大部分情况下 感觉不出来什么差异，必要性也不是那么强烈，当然你有兴趣的话 也可以提 pr 过来看下。。