记录一下编译 mlterm （framebuffer）的过程，以后继续折腾可以作为参考。如果对他人亦有帮助，则不胜幸甚。目前网络上基本找不到这方面的文章，该记录来自于阅读 mlterm 的 README 文档及手动编译的亲身经历。
mlterm gtk 及 framebuffer 两个版本是可以共存的，执行文件分别名为 mlterm 和 mlterm-fb。需要两次编译才行。一般说来，这种编译都不会有啥问题，无非 ./configure - make - make install 那套流程，但 mlterm 的编译确实有坑：
-
syntax error near unexpected token `(’ at 10000 lines（行数记不清了，多处相同错误）
执行
./configure --with-gui=fb命令，跑不了 10 秒钟就出现该错误。解决办法：切到 bash 下编译。
一般认为，zsh 语法是与 bash 相兼容的。 但显然还没到完全兼容的程度。 具体到该错误，zsh 下需要对该出错行中的括号进行 escape，而 bash 则不必。
-
syntax error: unexpected end of file at 28526 行（真的，configure 文件很长）
问题是： 文件行数总共“才” 28525 行。 该错误提示真是别具一格，成功做到了 错误提示与代码行数完全无关 。不得不说，shell 真是一门神奇的语言。
解决办法：19876 行少了个右双引号，补全即可。
显然，这是一处 bug 。缺少这个引号，
./configure命令不可能执行成功。可能是作者不小心删了，然后 commit 前也没有最后测试一遍脚本。 -
configure文件的格式混乱问题。（我理解 28525 行代码是个巨大的工程，但格式混乱这么简单的问题是可以避免的？）代码缩进不统一，有时用 2 个空格，有时用 4 个；而且是空格 + tab 混用。
这导致定位第二个问题，花费我这个 shell 编程白痴诸多时间。代码折叠完全不起作用，试图用
shfmt格式化代码也无效。最后快要放弃时，天可怜见， 肉眼瞥见 了那个该死的双引号。解决办法：文档页首有 Emacs 的 Single-line Variables 字符串，建议作者改用 Vim 编辑器？
或者，通知作者打开 Emacs 编辑器的 不可见字符开关 ？
framebuffer 版本编译安装完成后，执行 make clean 命令，再 继续编译 gtk 版本 ：./configure --with-gtk=3.0 --with-tools。fcitx、ibus 等输入法支持是默认的，不必理会。--with-tools 选项将会编译 mlconfig 等配套工具，这样方便进行图形化配置，而不必研究配置文件怎么写、有哪些可用选项等问题。
X 桌面环境下打开 mlterm，按住 Ctrl 键并右键单击，可以调出 mlconfig 图形化配置工具 。
mlterm 的配置文件位置在 ~/.mlterm 文件夹下，使用 mlconfig 工具可以自动写入配置。其配置样本在 /usr/local/etc/mlterm 文件夹下，可以将其复制到 ~/.mlterm 目录下，方便对默认配置做进一步更改。
重点关注的几个文件：
-
main- 主配置文件。mlconfig写入的也是这个文件。 -
font- X 下的字体显示。 -
font-fb- framebuffer 下的字体显示。 -
color- 颜色主题。 -
aafont- 尚不清楚，但比较重要。下次折腾时，再详读文档。 -
key- 按键绑定。不太重要。
折腾结果：
折腾 mlterm 的本意，是想替换掉不再维护的 fbterm。不过由于 mlterm 的性能问题，最后决定暂时搁置。
继续以 fbterm 为主力，并对 mlterm 保持关注。
mlterm 的几个小问题
下次再折腾 mlterm 起码也在一年半年以后了（这种底层工具 + 性能问题，不能指望在短期内能有所改善，还好 fbterm 目前还堪用），所以多记录一点不是坏事。估计半个月以后，我都不记得 mlterm 是个什么类型的软件来着？ 
昨天忘了记录 mlterm 除性能之外，其它几个小问题（及可能的解决方案）：
-
fcitx 输入法问题。
没有对比就没有伤害。显然，fbterm 默认自动读取 fcitx 的配置。这使得 fbterm 与 X 下的输入体验高度一致，包括 a) 除
Ctrl + Space键切换中英文状态外，还能用我自定义的Shift键；b) 选词列表横向，而不是默认的纵向；c) 候选词数及其它细节定制。优先级：低。等 mlterm 性能好转后，再提 issue 让 mlterm 读取 fcitx 配置。
-
字体配置问题。
尽管 mlterm 有图形化配置工具，但涉及到字体的配置，依然繁琐。而 fbterm 则是直接继承自 X 下的字体设定，几乎不需要配置。
存在的问题：
a) 对 mlterm 字体的 fallback 机制仍然没有搞清楚，目前状况是”好像好使了“。下次折腾时得搞清楚，当然前提是 mlterm 性能问题得以解决，这样才有足够动力去读文档。
b) vifm 的文件图标无法显示。vifm 图标用的是 devicons 字体，所以这个问题本质上还是 搞清楚 mlterm 的 字体 fallback 机制 。
-
cmus 播放器布局撕裂、部分不可见问题。
具体表现为 cmus 启动后，左边的播放列表及进度信息不可见，偶尔界面布局撕裂。奇怪的是，切换 colorscheme 后变为可见，退出 cmus 再进亦可见。如果使用 mlterm 初次打开 cmus，则问题必定出现。
深度怀疑，还是 mlterm 性能低下的坑。
-
tmux 下色彩支持下降问题。
mlterm 启动后默认为 256 色支持，但启动 tmux 后色彩支持下降到 8 色。tmux 在自身配置文件内将 term 声明为 screen-256，按说色彩支持不该下降（fbterm 就没有问题）。
得搞清楚配置问题在 mlterm 或 tmux 身上，需要修改其中一个的配置文件。
优先级：高。
-
ranger 行内图片预览
与 X 下一样，ranger 在 framebuffer 下依然能使用 w3mimgdisplay 进行图片预览。但该特性在 mlterm-fb 下失效。
mlterm 亦以 sixel 格式（包含动画）支持图片预览，但可能过分依赖自身组件？需要搞清楚 mlterm 是否支持 w3mimgdisplay 图片预览？（如不支持的话，）如何对 ranger 进行配置，彻底切到 mlterm 的 sixel 格式？
-
w3m 浏览器内图片显示失效
与上一个问题本质一样。但相对 ranger，w3m 图片无法显示更让人无法接受。
貌似 w3m 有编译选项支持 sixel 格式？可能需要重新编译 w3m。
对 mlterm 的期待和展望
目前 mlterm 和 fbterm 是 世界上唯二两款 可以在 framebuffer 下正常工作，且 支持中文显示及输入法框架 的终端程序（个人已知的）。
鉴于 fbterm 已停止开发（除了这一点，没有其它明显缺陷），长期看来，希望 mlterm 能 改善性能，最终替代 fbterm 。