GNU TeXmacs本身是一个排版软件，不过也支持查看cpp/py/scm等代码文件。
与Emacs类似，TeXmacs采用Guile作为扩展语言。我目前是GNU TeXmacs的维护者之一，一直有用GNU TeXmacs编辑代码的想法。未来会做一些尝试。希望能实现一些必要的接口，最终能够复用一些Emacs里面的丰富的插件。不知道各位有没有兴趣？
第一步，我是想复用Emacs里面已有的对各门语言的高亮。
这是我今年的开发计划：[NEWS] My Development in 2019 on GNU TeXmacs (sadhen) - Community - GNU TeXmacs Forum
明年或者后年，我会开始做代码高亮这件事。
maintainer本人来了，真是稀客。
我常用texmacs打一些公式，很方便，谢谢你们的工作。
不过texmacs现在打字总感觉卡卡的。
听说guile可以读取elisp，不过我没有试过，是否可行呢？
卡顿的问题可以看这篇帖子：通知：请不要使用GNU TeXmacs 1.99.8这个版本 - 知乎
具体有问题的那个commit我在帖子里面的v2ex链接说明了，你自己编译的时候可以把有问题的那一行代码删掉。现在是莫名其妙有一个100ms的延时，所以卡顿。
我觉得是可以期待的，不过没有那么多精力去做尝试。
这是我今年的开发计划：[NEWS] My Development in 2019 on GNU TeXmacs (sadhen) - Community - GNU TeXmacs Forum
我觉得有一定难度。
Emacs 的高亮用的是一个很 primitive 的 API，叫 font lock，这个 API 是基于正则的，正则还是挺好实现的。但具体的显示又基于一个更加基础的 API 叫 text-property，说白了就是 GNU/Emacs buffer 中每一个字符都有一个属性列表来控制显示。我估计和 TeXmacs 的内部数据表示有极大冲突（我不熟悉 TeXmacs 的实现，但是根据对一些文字处理软件的通识，TeXmacs 的 inner representation 可能更像 markup）。而 Emacs 用了一个特殊的 hack 避免编辑时频繁扫描 buffer，就是新输入的字符会自动继承周围的 text property。
而处理 font lock 相关的配置本身就是需要有能力 eval 一部分 emacs lisp 代码的，因为 font lock 不是一个特别的配置格式，而是用 elisp 代码构建出个 alist 传给API。
还有些特例情况，比如 Agda 因为格式非常灵活，需要由语言后端直接调用 text property 来高亮。
对我来说 TeXmacs 作为一个排版软件更有吸引力的功能在于 listing，也就是不用高亮，单纯用排版让代码显得很有格调：
上图是 LaTeX 的 polytable 包示例，但用法非常复杂，是专门写了个预处理器从纯文本 Haskell 代码生成 latex macro 才实现这种效果。
我非常期待有可视化的软件能完成这个功能。
还有为了性能用二叉树储存text property。
如果只是借用已有的正则，不需要底层实现一样吧。我觉得不用担心这个问题
正则感觉不是很妙啊，据我了解，正则的性能都是不怎么好的。
这块后续我还是参考一下Kate里面的高亮吧。
准确的说是基于match-data的，match-data会记录re-search-forward这些搜索API的查找信息。
ELISP> (with-temp-buffer
(insert "foobar")
(goto-char (point-min))
(re-search-forward "foo\\(bar\\)")
(mapcar #'marker-position (match-data)))
(1 7 4 7)
font-lock-keywords的docstring提到
where MATCHER can be either the regexp to search for, or the
function name to call to make the search (called with one
argument, the limit of the search; it should return non-nil, move
point, and set `match-data' appropriately if it succeeds; like
`re-search-forward' would). MATCHER regexps can be generated via
the function `regexp-opt'.
所以可以用其他手段解析buffer contents 然后手动set-match-data改掉这个match-data，从而利用font lock机制直接上色。
那就完全做不到po主直接复用 emacs 的高亮定义了，众所周知 emacs 高亮定义都是正则写的。要重写还不如按照 jb 和 vsc 那样用语法树做高亮好，语法定义就能直接拿来用，重新写也不难了。然而po主会想复用说明在编程语言环境上苦手，只想着能在哪里抄抄就好了，问出来这个问题其实也是太 naive。
有偷懒的方法，自然不想自己一行一行码
最近很火的tree-sitter，或许可以考虑一下
原来苦手是不擅长的意思。。。之前以为苦手是很苦逼地用自己的手造轮子。。。
确实不擅长的，毕竟没有正经做过编程语言的高亮。
代码高亮这个事情的关键在于把框架制定好，然后自然会有相关语言的爱好者来贡献具体的高亮定义。目前有一定进展，感兴趣的小伙伴可以看
这样的话就又造了一个轮子 这个轮子好不好呢 效率高不高呢？关键的是 他能经受的住时间的考验吗？
为什么不用已有的轮子？看懂别人的代码比自己写要难。
我觉得vim的高亮规则就不错，基于正则表达式。emacs的高亮也是基于正则的。
现在的neovim已经集成了tree-sitter，高亮只是他最初级的应用。
我觉得可以移植vim的正则表达式和语法高亮。
还有一个更简单的方法是，用texmacs作为neovim的front end。
TeXmacs 好样的，我是一个数学爱好者，一直用 TeXmacs 写作数学讨论稿和打草稿作交流之用，当然正式文档还是用的 LaTeX。TeXmacs 简直就是数学神器呀，用上了它之后，我电脑中很早就删掉了 word，mathtype 之类的东西。
差不多一年过去了 高亮的事情其实做得差不多了 只剩下多行字符串 多行注释这种支持还有一些问题
后面有时间会和大家分享一下我实现代码高亮的思路
支持www 很好奇你最后用的是什么方案
没啥方案，反正干活就是了。有牛炸天的方案，没有人coding，到头来还是一场空
我在上面的帖子里面贴了代码链接了