关于Org-mode文学编程时自动补全代码的问题

优势就是,有许多编写代码的工具可以直接用, 劣势就是: 编写文档的时候只能用脑袋解析和手敲, 但如果使用轻量级的标记语言,这个就不是什么大问题了。

确实,org 当中代码块多了确实不好管理。

简直是噩梦, 当年pyim就是使用org化的文学编程组织代码的,后来发现太TM痛苦了, tangle一次要好几分钟,而且它直接让 emacs 的增量编程方式从稳定降低到不靠谱。。。。 后来我改成用comment的方式了

1 个赞

但是这也是 org 的优势,就是能够把各种语言粘到一块。不知道你用不用 org 表格的 Spreadsheet 功能,相当强大,和 src block 一起完全可以取代 Excel。

如果只使用一种语言确实没有必要文学编程了。

这个我感觉是一种黑科技,而不是一种特性。 多种语言混用,本身就是维护黑洞。 org 表格的 Spreadsheet, 我只有做统计分析的时候用过,其他时候我尽量避免使用它。

文学编程就算了, 写好代码和文档,做好代码文档一致,就需要很大的精力了

org table 的一个主要功能我觉得是作为代码块的输入或者输出。

反正 org 还有很多黑科技,要完全掌握很困难。

嗯,这在统计分析里面很好用, 编写可重现性报告的时候, 数据和代码用org,组织在一起确实很方便。

因为统计分析的时候,用到许多不同的工具, 数据获取的,清理的, 制作图表的,转换图片的, 分析数据的,等等, 用org将他们黏在一起,实现半自动化后,会方便很多。。。。

:joy: 这不就是 org 的目标用法吗?比较而言,编写大段代码的工作确实不适合 org,我也从来不把它用做开发工具。

对,确实如此。

虽然 Spreadsheet 强大,但 Org-mode 上的 Table 很难看啊。而且 Emacs 没法真正地上下左右平滑地滑动,看一个 Org-mode 输出的 Table 太反人类了。

真希望 Xwidget 这类功能能整合到 Org-mode ,这样 Org-mode 能用 Python 中 Bokeh 和 Plotly 这类库画出的图了,也能够输出可读性高的 Table 了。

同样道理,org table 也有局限,不然你让其它软件怎么活。而且有些 featrue 实现起来对于 orgmode 的开发者来说可能也比较困难吧。毕竟 emacs lisp 也是比较古董的存在,很多 gui 功能都受到 emacs 自身的限制。

好像 JK 还搞过 orgmode 下使用数据库,但这个我就不太了解了。他的博客上都有。

这是 Emacs 最近新出的 SQL 数据库插件,大部分用 C 语言写的, JK 要搞的数据库好像是 Mongodb。

我记得以前看过一篇王垠写的博客,Scheme 的编译器 Chez-scheme。去年 Chez-scheme 开源了。 现在 Rocket 换 Chez 当内核了,有时在想:要不 Emacs 也试一下 Chez 当解释器,虽然不知道行不行,还是异想天开,Chez 的速度比 Guile 快太多了。而现在连 Guile-Emacs 的影子都看不到。

2 个赞

这个牛很萌呀

Guile-Emacs 就一个人在搞,而且每次都是在 google编程暑假的时候搞一搞,按照这种进度, 5年代码都不可能达到 emacs 要求。 我个人感觉 elisp 的未来可能有几种: 1. 保持现状 2. 平稳的优化,逐步去掉过时的特性 3. guile-emacs 4. emacs 个屁

1 个赞

先等 GNU/Hurd 正式发布再说。

5年内,把并发的问题解决了就不错了