连续遇到编码问题, 发现一个原则, 也是c语言作者反复强调的: 简单直白才是好的方案

vscode双栏展示
  1. ai的第一建议普遍是搞两个webview, 如果你这个双栏还要编辑, 那么就在webview里面放Monaco或者codemirror. 泰裤辣, 这么干真是泰裤辣…. 呵呵呵, 这么干至少1个月就能轻松的度过了.
  2. ds可以建议你直接双栏, 他帮你搞双栏展示, 然后, 你发现自己面临一系列困境:
    1. 分栏之后,
      • 如何保证分栏被识别为markdown, 这是最容易解决的问题.
      • 分栏之后, 如果不处理, 那么用户无法区分究竟哪些是分栏, 那个是左, 那个是右, 真的, 别笑, 尤其是开发的时候, 面前有三个分栏, 真不知道他们的映射关系, 此时我们要装饰分栏, 也不算太难解决.
      • 分栏之后, 还可以再分栏, 会导致无限分栏的死循环, 我们可以去掉手动分栏这个选项避免用户分栏. 但是, 自动触发分栏也可能死循环.
    2. 同步机制会在两个节点导致死循环
      1. 分栏创建时, 编辑器editor创建没有异步等待过程, 因此此处会导致无限循环保存, 此处我们的分栏操作, 和系统的编辑器创建以及自动保存形成了完美的线程交织….
      2. 分栏和主文件之间的同步机制, 即便做单项同步, 但是架不住还有vscode的自动保存, 一样的能死循环.
  3. 实际上自动两个临时文件, 当用户打开a.ye时, 我们并不直接打开a.ye, 而是, 直接建立两个临时文件: a.ye.左.md, a.ye.右.md, 然后分栏打开这两个文件.
    • 然后, 我们也不需要搞同步机制, 只要用户关闭左.md时, 把右.md也关闭, 并且把他们两个的文件内容合并为a.ye, 然后删除掉这两个临时文件(可选, 不做似乎也没啥问题).
    • 这样我们就解决了所有问题: markdown格式, 无限分栏, 同步循环, 2个分栏的装饰区分.
顺便说一句, 面对原始需求, ds的第一次思考, 他就已经把3种方案都排出来了,

  • 但是, 在这件事的判断上出了问题, 他的初始判断其实是对的. 分2个文件时最简单的做法,

  • 但是, 他把文件同步放到了一个很高的考虑点上.

  • 而其实此种情况下, 我们是无法考虑文件同步的.

    • 除非自己实现一个编辑器, 不然在vscode的限制下, 要把同步写好, 至少得1个月.
    • 并且即便要把同步写好, 2个临时文件的方案也好过前面两个方案. 但是, 在这个地方ai莫名丢分了.

这个丢分情况类似于之前对比pyside方案和前端tauri/svelte方案, ai的结论是: python慢, 前端快

  • 原因很简单:
    • 前端方案他们的对比都是在前端范围内进行对比, 就仿佛是幼儿园成绩.
    • python每次都是和c比运行效率和ruby比开发效率. 他是参加奥运会的选手.
  • 此时破解, 就是让ai把表格列出来, 究竟开发要几天, 运行是个什么tps,
    • 此时搞笑的是, pyside2天, t/s7天, python1m/s, t/s 1k/s, ai依旧会说, python开发效率不如t/s方案, 运行效率也是t/s完胜…..
    • 果然是大语言模型, 听从大多数人的意见.