GNU TeXmacs 招募开发者

[sadhen]

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。

相关链接

• GNU TeXmacs 的知乎专栏
• 如何参与 GNU TeXmacs

Github 地址： https://github.com/texmacs/texmacs

[shell314]

支持

[skt041959]

需要人手的话，不妨先考虑迁移到 Github ？

[fengjianxinghun]

看了下 cpp 部分…没有 STL 没有现代 c++…这些轮子真不如 STL

[luozic]

github 要不这不好提交和查看代码把

[willm]

支持。没有用过这个东西

[qcts33]

为啥不使用 C++和 C 的标准库呢……

[QNLvw5fLfr7c]

支持&感谢, 看王垠推荐了解的这款编辑器, 很好用.

[sadhen]

@skt041959 见附言

[sadhen]

@fengjianxinghun 所以我说有很大的优化空间，另外不要盲目崇拜 STL

[sadhen]

@luozic 见附言

[xnode]

支持,但是我的支持可能没啥卵用

[hiouyuu]

Texmacs 的速度要求很高吗？如果不是为什么在性能上做那么多优化？

[omph]

支持，不过没用过

[sadhen]

@xnode https://www.v2ex.com/t/562845 可以这样支持

[BIAOXYZ]

从本科毕业时候知道 latex （但是本科毕设还是用的 word ）开始，用了好多年 latex 了（ TeXmacs 就是之前下载过简单试了下，没深入用过）。不知道加入后能做点什么？时间上会有很紧的 deadline 吗?跟题主面临的问题一样，可能只有周末有时间。

[ipwx]

@sadhen 虽然崇尚自己的轮子，便于优化可以认为是优点，但是从开发效率来讲，也是一种缺点。我几年前用过 TeXmacs，从用户角度来讲，很多时候功能不够用是最大的问题，而不是效率。而且最终如果要导出成 LaTeX，当年的体验是排版错乱很严重，所以也不是很好用。

另外 TeXmacs 使用自己独特的文件格式（也可以看作一种自己造轮子？），也是阻碍更广大用户接受的大问题。感觉最近几年 LaTeX 和 Markdown 编辑器的易用性都上来了，前者有 Texpad （自己造了个 LaTeX 子集的实时编译器），后者有 Typora （所见即所得，公式支持也不错）。这两类格式用的都比较广泛，相关工具链也比较完善。所以 TeXmacs 还剩下的特色功能到底是什么呢？

[sadhen]

@ipwx 我不是 LaTeX 的用户，我是把 TeXmacs 当作 Word 这样的东西来使用的

[sadhen]

@BIAOXYZ 时间上都是自由的，欢迎欢迎

[dalieba]

@sadhen Lyx 了解一下

[caizheng]

用过几年 texmacs，感觉确实不如 texmaker 和 texstudio。那么问题来了，怎么加入？

[SamsonWang]

作为 emacs 的重度使用者，我对这个项目很感兴趣。我担心的是自己没有足够稳定的时间参与开发。

[sadhen]

@SamsonWang 只要你足够感兴趣，时间上绝对不会是问题

[sadhen]

@caizheng 请看相关链接第二个：如何参与 GNU TeXmacs?

[24owls]

Guile 的版本升级记得几年前就计划了，竟然还没有完成吗 :(

现在 TeXmacs 有关的信息感觉比较分散，texmacs.org 上的信息旧，新的信息又没有地方可以找，只有翻翻邮件列表才能稍微了解一下这个项目的开发

不妨集中整理一下这个项目的现状和文档，更新一下 texmacs.org ，或者更新 texmacs.org 有其它困难的话，就把可以帮助 contributors 的信息放到 github pages 上，具体介绍一下这个项目的现状

比如，现在的 TeXmacs -> Help -> Full manuals -> Developers Guide, Scheme Developers Guide 里面的信息还是准确的吗？

比如，假设现在有一个人想帮忙迁移 Guile 的版本，这个人只了解 Guile 但是对 C++ 一窍不通，这个人需要了解的信息要到哪里去找呢？ C++ 和 Scheme 的边界在哪里？哪些事情是 Scheme 完成的？

感觉把文本资料整理好，这样才好吸引新的开发者吧 :)

[luozic]

1.文档跟踪和编制在大项目维护里面 甚至比代码本身重要
2. 使用业界标准的轮子，除非你自己就是业界标准的好处在于 跟随性的优化。llvm 在静态检查和代码本身上面比 gcc 好多了。 当然可以在标准化的轮子之外使用自己的小特定轮子，但是转换必须预先定义好，等到标准化轮子比自己的好的时候 果断替换，自己优化比标准好的时候 提交 patch 的同时 临时搞自己的轮子。
3. 要想大家快速使用 要么推专家的专业标准 要么贴近一般人的所见即所得，啥都不靠 自己还有问题 意味着客户自动流失。

[lcj2class]

mark 抽空看下相关文档

[sadhen]

@24owls

2016 年的时候，我尝试过给 Guile 升级，但是遇到困难。

TeXmacs 内置的文档是比较全的，里面的信息大部分是准确的。

如果要迁移 Guile，本身需要了解 C++和 Scheme 的，这是比较困难的，即使写了文档，99%的程序员都是搞不定的。

[sadhen]

@luozic GNU TeXmacs 的文档其实是很完善的，是内置的。

所有的文档： https://github.com/texmacs/doc

[PapaFox]

@sadhen 大佬，请问你有计划往 TeXmacs 里加入中西文混排的功能吗？像 Word 或者 ctex-kit 一样可以让中西文之间加入一点空格？多谢！

[sadhen]

@24owls Guile 升级已经有进展了。see https://github.com/texmacs/TimScheme/issues/2

最近这段时间就要发布 TeXmacs 2.1 了，后面会把 Guile 2 和 Qt 5 的升级做起来。

[sadhen]

@PapaFox 有计划的，这块我后续会优化