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。
1
shell314 2019-05-10 08:41:57 +08:00 via Android
支持
|
2
skt041959 2019-05-10 08:45:57 +08:00
需要人手的话,不妨先考虑迁移到 Github ?
|
3
fengjianxinghun 2019-05-10 09:21:31 +08:00 via iPhone
看了下 cpp 部分…没有 STL 没有现代 c++…这些轮子真不如 STL
|
4
luozic 2019-05-10 09:53:27 +08:00 via iPhone
github 要不这不好提交和查看代码把
|
5
willm 2019-05-10 09:53:57 +08:00 via Android
支持。没有用过这个东西
|
6
qcts33 2019-05-10 11:07:11 +08:00
为啥不使用 C++和 C 的标准库呢……
|
7
QNLvw5fLfr7c 2019-05-10 11:12:34 +08:00
支持&感谢, 看王垠推荐了解的这款编辑器, 很好用.
|
9
sadhen OP @fengjianxinghun 所以我说有很大的优化空间,另外不要盲目崇拜 STL
|
11
xnode 2019-05-10 13:16:35 +08:00
支持,但是我的支持可能没啥卵用
|
12
hiouyuu 2019-05-10 13:35:39 +08:00
Texmacs 的速度要求很高吗?如果不是为什么在性能上做那么多优化?
|
13
omph 2019-05-10 13:36:17 +08:00
支持,不过没用过
|
14
sadhen OP @xnode https://www.v2ex.com/t/562845 可以这样支持
|
15
BIAOXYZ 2019-05-10 14:30:58 +08:00
从本科毕业时候知道 latex (但是本科毕设还是用的 word )开始,用了好多年 latex 了( TeXmacs 就是之前下载过简单试了下,没深入用过)。不知道加入后能做点什么?时间上会有很紧的 deadline 吗?跟题主面临的问题一样,可能只有周末有时间。
|
16
ipwx 2019-05-10 14:33:51 +08:00 1
@sadhen 虽然崇尚自己的轮子,便于优化可以认为是优点,但是从开发效率来讲,也是一种缺点。我几年前用过 TeXmacs,从用户角度来讲,很多时候功能不够用是最大的问题,而不是效率。而且最终如果要导出成 LaTeX,当年的体验是排版错乱很严重,所以也不是很好用。
另外 TeXmacs 使用自己独特的文件格式(也可以看作一种自己造轮子?),也是阻碍更广大用户接受的大问题。感觉最近几年 LaTeX 和 Markdown 编辑器的易用性都上来了,前者有 Texpad (自己造了个 LaTeX 子集的实时编译器),后者有 Typora (所见即所得,公式支持也不错)。这两类格式用的都比较广泛,相关工具链也比较完善。所以 TeXmacs 还剩下的特色功能到底是什么呢? |
20
caizheng 2019-05-10 18:09:20 +08:00 via Android
用过几年 texmacs,感觉确实不如 texmaker 和 texstudio。那么问题来了,怎么加入?
|
21
SamsonWang 2019-05-10 18:18:35 +08:00 via Android
作为 emacs 的重度使用者,我对这个项目很感兴趣。我担心的是自己没有足够稳定的时间参与开发。
|
22
sadhen OP @SamsonWang 只要你足够感兴趣,时间上绝对不会是问题
|
24
24owls 2019-05-11 03:18:19 +08:00 1
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 完成的? 感觉把文本资料整理好,这样才好吸引新的开发者吧 :) |
25
luozic 2019-05-11 07:12:21 +08:00 via iPhone
1.文档跟踪和编制在大项目维护里面 甚至比代码本身重要
2. 使用业界标准的轮子,除非你自己就是业界标准的好处在于 跟随性的优化。llvm 在静态检查和代码本身上面比 gcc 好多了。 当然可以在标准化的轮子之外使用自己的小特定轮子,但是转换必须预先定义好,等到标准化轮子比自己的好的时候 果断替换,自己优化比标准好的时候 提交 patch 的同时 临时搞自己的轮子。 3. 要想大家快速使用 要么推专家的专业标准 要么贴近一般人的所见即所得,啥都不靠 自己还有问题 意味着客户自动流失。 |
26
lcj2class 2019-05-11 11:24:04 +08:00
mark 抽空看下相关文档
|
27
sadhen OP @24owls
2016 年的时候,我尝试过给 Guile 升级,但是遇到困难。 TeXmacs 内置的文档是比较全的,里面的信息大部分是准确的。 如果要迁移 Guile,本身需要了解 C++和 Scheme 的,这是比较困难的,即使写了文档,99%的程序员都是搞不定的。 |
28
sadhen OP |
29
PapaFox 2019-09-05 21:11:30 +08:00
@sadhen 大佬,请问你有计划往 TeXmacs 里加入中西文混排的功能吗?像 Word 或者 ctex-kit 一样可以让中西文之间加入一点空格?多谢!
|
30
sadhen OP @24owls Guile 升级已经有进展了。see https://github.com/texmacs/TimScheme/issues/2
最近这段时间就要发布 TeXmacs 2.1 了,后面会把 Guile 2 和 Qt 5 的升级做起来。 |