可以，但没必要。我试了，明确告诉AI使用哪些 unicode 字符，它可以绘制表格，但是中英文混合时始终对不齐；纯英文的情况也不完全能对齐，且需要多次提示，思考时间很长。这种事情还是交给能够精确控制的程序更合适，AI只能使用 unicode 字符如各种全宽、半宽、零宽的空格来补齐对不齐的部分，而 emacs 可以将空格显示为指定像素的宽度(valign) 或 调整字体宽度(cnfonts) 等手段来对齐。
下面我是用AI生成的：
你这个需要的是一个 emacs 里面的 excel 呀，哈哈哈。
是这样的。什么时候ai能够训练到grid-table的相关数据应该就可以了。
是否有可能实现一个将现有org-table转换为grid-table的辅助工具？
ai确实可以定制这类表格。不过我倾向于有工具生态支持的格式，比如org-table，接下来的grid-table等，毕竟有的时候需要手工编辑调整，都要让ai做也有麻烦。
谢谢建议，之前没想过这个方向，先作为需求记录下来
1 个赞
谢谢。如果这个工具在转换时候，能够将表格宽度做一定的智能控制就太棒了（比如自动将一个cell太长的文本换成多行）。我现在让ai帮我整理的表格，经常太宽，导致在源文本形式下没法看，只能临时导出成html查看。
这个不用担心。 grid-table 本身限制单元格的宽度。
1 个赞
我的意思是垂直方向的滚动条，比如数据行数很多，屏幕能显示一部分就可以了，看不见的部分自己用滚动条上下滑动。
不需要，已经实现你说的设计。
另外，你如果要滚动条，就自己手动开启 emacs 内置的。
Emacs是富文本编辑器，底层上有实现的可能性，记得以前emacs mailing讨论过。
Emacs 不是富文本编辑器，它只是动态计算并显示对应的效果，但这些是不保存到文件里的。不是可以显示多几个样式就叫富文本。
Word 是富文本编辑器，是因为从编辑器到文件格式，都是支持富文本。
富文本与纯文本编辑器的分野在于，面向的对象是谁。面向纯文本就是纯文本编辑器，面向富文本就是富文本编辑器。
可以实现的，我正在做这方面的工作。一切编辑器最初都是纯文本，通过一个通用的底层模型AST，就可以实现所谓的富文本。word好像用的是xml，emacs只需要定义自己的模型 和 良好的前端交互方式就可以实现类型 excel，word 的效果(包括前文提到的滚动的效果等等)，从理论上是完全可行的，只是要做大量的工作。
3 个赞
是的，插入到 org 表格里的， 相当于一个预览，你只能查看。 如果你要编辑，或者别的操作，还是在 grid table 的独立窗口里操作。
当前无法显示图片是因为里面保存的图片信息被破坏掉了。但实际上你重启一次 emacs 之后， 它也会丢失，因为 emacs 的文本属性只能临时添加信息，不能持久化。
不确定要不要做一个动态解析的模块，这会有一定的性能消耗，我不希望导致 Emacs 卡顿。
还是等多线程吧，按照现在的基础，即便实现了这么复杂的显示效果，以及文本格式，以现在单线程的状态，只要渲染多一些文本，可能都会卡顿。至少现在应该把显示渲染独立成一个线程，不然大家日常遇到的卡顿那是再正常不过了。
理论上 emacs 是无所不能，但现实中，不能脱离它的现实限制。
当然更深度的讨论就是，如何持久化 text properties 里的信息，基本上 text properties 里是万能的，什么都能塞，这也是 emacs 的样式可以如此丰富，甚至讨论把它当成 Word 来使用。这里还有一个问题，就是这些文本属性如何保存，以及如何解析。
当然，grid table 已经部分解决以上问题。
2 个赞
动态交互是增量更新的，并不会卡；首屏绘制可以把计算的工作用 rust 动态模块的多线程来实现，应该还可以。emacs-kp 我之前测试过动态模块，性能提升很明显。动态模块适合用来做计算密集型的工作，利用计算机的多核并行返回计算结果给emacs，但是 UI 的频繁大量更新，动态模块解决不了(但我们可以通过各种手段规避，vue的数据驱动和增量比对更新，elisp 的 add-variable-watcher 让这一切成为可能)。当然如何能够有多线程，一切都不用烦了，只是 懒猫大大都解决不了的问题，且社区讨论了这么多年都没有啥进展，可见非常困难，我也不报什么期望了。
当然使用类似 holo-layer 的方案是可行的，就是另外绘制图形，然后输出回 emacs。我说可以等，是因为多线程目前有进展了，不管快还是慢，总之在推动了，只是不知道什么时候合并就是。
动态增量更新我也尝试过， 我发现太容易出问题了，尤其是在局部重绘方面，只要你的界面是动态的，动态增量更新就基本废了。当然，我本人的水平未必足以解决这个问题，但是我尝试了好几种方法，都没能彻底解决。
使用动态模块只有一个问题，就是会加重用户心智的负担。org-supertag 的 python 部分，最近就好几个人跑过来问我怎么安装。
1 个赞
grid-table 最新进展：
在用户使用非等宽字体的情况下，依然可以整体地显示表格。
1 个赞
多线程的进展我确实是不了解了，没想到一直在推进，是值得高兴的事情！
我能理解你说的增量更新的问题。解决这个问题的核心在于如何记录用户的实时操作对于结构带来的改变。只要数据模型始终是最新的，增量更新就没有问题。或许你可以尝试在特定的范围内使用 post-command-hook 来记录变化？但频繁触发这个hook不保证不会有性能问题，需要做优化。
因此，我觉得类似这种需要支持复杂功能的表格或页面，还是更适合在一个“受限编辑”的 buffer 中进行：即部分结构是只读的，不允许用户直接修改(比如合并单元格不允许通过直接删掉边框来合并)；如果要修改，也只能通过命令，然后这些命令负责持久化结构的更新。这种限制，牺牲了实时编辑的灵活性，但可以实现完整的功能。事实上 excel 也是这样的，它本质上还是一个前端的展示，背后是使用 xml 来记录结构和数据的。
确实，动态模块的心智负担是个问题。我们只能在一定程度上对一些频繁的操作进行封装来改善用户体验，我之前开发 emacs-kp 时写了几个函数用来重新编译和加载动态模块，还算好用。但是，比如安装 rust 和 cargo 环境这种事情必须要手动去做了，但这也是一次性的。
动态模块编译和加载相关的命令在这里：
通过DSL结构来持久化，即我预先定义了一个结构，这个结果经过解析之后就包含了所有的 text properties 信息。当然结构的定义一定是简单的，不会像代码那般复杂。DSL是一个初始结构，当页面渲染完成之后，这个结构本质上是在内存中的一棵树，后续的所有动态的交互都在内存的树结构中进行，然后增量更新页面。如果需要保留当前最新的页面结果，只需要保存这棵树对象的打印表示，或者反编译为 DSL 即可，这些结构的文本存在哪里都可以。
上面所说的并非实时编辑的场景。你可能说的是在文件中的实时编辑，我的想法是如果要功能可拓展性强，最终只能使用数据库来存储。或许文件存储够简单，但是拓展起来就会很麻烦，不如一步到位。