GNU TeXmacs 是一个大概有 20 年历史的 GNU 项目,目前在代码仓库提交代码的开发者(包括本人)一共 7 人。其中,C++的代码量和 Guile Scheme 的代码量都是在 10W 这个量级的。
本人是从 2013 年开始加入这个项目,在过去的六年时间里,目前一共提交 198 次。
一开始只做文档翻译,后来只是简单修复一下一些中文的乱码问题,最近两年修了一些特别影响使用的和中文用户相关的问题,最近这段时间正在将我之前写的 Git 插件整合到代码仓库中。开发的进度会比较慢,因为在中国做程序员相对还是比较忙的,我基本上只在周末开发。
这个项目整体上的设计是非常棒的,代码从某种意义上还算整洁,个人认为代码质量优于我看到的一些别的 C++的开源项目。但是,目标太宏大了。
目前最困难的问题是,GNU TeXmacs 还在用旧版本的 GNU Guile,而这个版本(1.8)已经被 debian 移出了仓库,所以主流的 debian 和 debian 衍生版本[1],都无法通过包管理器直接安装,而是需要自己编译。而将 GNU TeXmacs 从 GNU Guile 1.8 升级到 GNU Guile 2.x,需要对 GNU Guile 2.x 非常了解,还需要精通 Scheme 的黑魔法——宏。
所以,我衷心地希望一些 LISP 黑客能够加入开发,大家一起研究 GNU Guile,一起解决这个最困难的问题。
当然,不仅仅是 Scheme 代码有很大的挑战,整个 C++的代码都有比较大的优化空间。GNU TeXmacs 没有使用 C++标准库,也尽可能不使用一些 C 的标准库,而是自己实现大部分的代码。这些自己实现的代码,我们很容易就能挖掘出很多优化点,做性能上的调优。个人有很多 Java/Scala 代码的性能调优经验,对 C++代码如何做性能调优还比较陌生。
另外,GNU TeXmacs 主要是使用 Qt 作为图形界面,也希望对 Qt 非常熟悉的小伙伴加入开发。但是 GNU TeXmacs 对这些 UI 框架的使用是比较谨慎的,尽可能使用最少的功能。因为 GNU TeXmacs 的开发相对缓慢,无法迅速跟上 UI 框架的更新,另外,本身设计上是支持多种 UI 框架的,并不绑定在某种 UI 框架上。
也非常希望一些经验丰富 C++工程师加入开发,大家一起讨论各种 C++技巧,优化 GNU TeXmacs 的性能。
最后,我得强调一下,这是一个 GNU 项目,采用的许可证是 GPL3。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.