ruki
有办法复现么，提供下之前的一些操作步骤。。 还有，那个时候有没有在编译或者有编译未完成的任务？xmake.lua 是否在编辑状态？ 如果没有编译，应该只有在 xmake.lua 有变动的时候，vscode 插件的 intelligense 会自动执行 xmake 重新生成下 compile_commands ，其他应该不会有进程执行才对。
跟这关系不大吧，插件里面会起 xmake 的地方，要么是 build ，要么就是 运行 `xmake l assets/xxx.lua` 脚本获取一些 modes/archs/targets 信息。 我感觉可能是某些 xmake 进程执行，因为用了包，可能触发 `-y` 输入确认提示，导致一直没能正常退出，否则按理应该很快就会退出才对。。 具体得先看下，是哪些 xmake 进程卡住了，没退出。 可以插件源码里 https://github.com/xmake-io/xmake-vscode/blob/master/src/process.ts 这里加点 logs 调下看看
可能是 死循环执行 xmake l update_intellisense.lua 导致。回头我调下。
我这没 win vscode 调试环境，macos 上我试了下，没啥问题么，没法复现问题，你可以直接拉下 vscode 插件源码，加载插件试试，然后提供下调试终端的 logs
就是用vscode 打开 xmake-vscode 插件目录，点调试运行就行了。里面加点 log 看看日志就好，然后配置一下 npm 什么的。。
xmake c -a 会强清配置，导致配置每次改动，触发插件内部重新执行 xmake l 更新所有状态，目前是监听 fs watch 配置文件改动，才会执行它 通常只有 xmake f 改配置了，才会执行 为啥需要执行 xmake c -a 这个呢，除非必要 不建议这么干
这是因为要同步 xmake 配置状态和状态栏/explore ui，所以通过 fs watcher 去监听 配置文件更新，然后通过 xmake l xxx.lua 去加载配置状态信息，目前这是必须的，暂时没其他更好的方案去解决。 主要是 win 下起进程比较重导致容易复现，但只要不频繁切换配置状态，就没事。。 或者可以看看有无其他更好方法可以避免起进程，或者减少子进程调用
I don't have time to support it now.
> In linux I managed to have utf8 running by simply linking to ncursesw. We also need to consider pdcurse with wchar. > There are some issues with drawing on...