那就让他本人来说, 如果有啥我不懂的, 我乐于学习。
讨论问题请列出详细的数据和事实, 正面回答问题, 不要一回答问题就是个人喜好和政治正确的言论。
不要一讨论问题就是我能C语言写, 不考虑经济行为和成本, 这是我一贯的观点, 明明世界上有现成的工具可以借力去完善Emacs这个工具, 非不用, 就说要用C去实现所有东西, 有多少人有理有据, 能够正面回答我上述帖子的问题呢? 而不是啥都是一个观点, 行动呢?
那就让他本人来说, 如果有啥我不懂的, 我乐于学习。
讨论问题请列出详细的数据和事实, 正面回答问题, 不要一回答问题就是个人喜好和政治正确的言论。
不要一讨论问题就是我能C语言写, 不考虑经济行为和成本, 这是我一贯的观点, 明明世界上有现成的工具可以借力去完善Emacs这个工具, 非不用, 就说要用C去实现所有东西, 有多少人有理有据, 能够正面回答我上述帖子的问题呢? 而不是啥都是一个观点, 行动呢?
你们讨论了一大堆,我个人觉得的问题是。emacs如果支持多线程会带来很多的问题,那说到底还是emacs 没有一套严格的渲染与逻辑分离的设计方案。关于多线程带来的问题,其实unity这种游戏引擎已经给出了实践方案了-------子线程严格禁止直接修改主线程的东西。
lsp-bridge/deno-bridge 这种做法不是和unity不谋而合吗。这样的做法很安全,进程隔离,lsp-bridge/deno-bridge没法直接操作emacs, 很大程度避免了多线程有可能导致emacs崩溃的问题。而且拓展了emacs不支持的多线程问题。
emacs自身很难做到多线程(我觉得也不用指望能有一套多线程的解决方案了吧)
多线程编程会有很多的问题,作为一个后端仔我比较欣赏用队列解决线程并发带来的问题。这也和lsp-bridge/deno-bridge的设计方案吻合。
所以现如今我觉得最好的方案就是用lsp-bridge/deno-bridge的方案去拓展emacs。
啥都用c写确实成本太高了。。