月度归档：2019年12月

当 Neovim 遇上 Acrylic

发表评论

dotnvim 是很久之前开的坑了，当时是想做一个颜值在线的 Windows neovim 前端。但其实我很少单独使用 vim，用也多半是在别的 IDE 里面用 vim 插件，所以这个项目也没怎么更新过；而且新的 Windows Terminal 完善之后，大概 dotnvim 存在的意义又下降了一分。但今天又打开看了一下，发现颜值其实还是挺不错的，居然又燃起了我间歇性使用 vim 的欲望⚠顺便再写一遍文章回忆一下当时开发时遇到的坑🤔

没有可用的 C# neovim 客户端

虽然当时在 neovim Wiki 的 Related Projects 里面有列出一个 C# 客户端，但实际看过就会发现功能欠缺很多，几乎处于不可用的状态。所以只好自己再造一个轮子了。neovim 与前端的通信使用的是 message pack，是一种很容易理解的协议。整个客户端的实现也很简单，就是 neovim 说什么，我们照做就行了——比如光标移动到哪里、颜色设置成什么、显示什么字符之类的。

但是只看 neovim 的 文档 还是会不明所以，所以搞不懂的时候就只能去翻官方的 Python 版或者是 Qt 版的客户端代码了。

Acrylic Blur

一开始我是打算做成 UWP 的，毕竟亚克力效果只有 UWP 才支持。起初考虑 nvim 需要自己单独一个进程，担心 UWP 不支持，结果是我多虑了。但后来翻了一下 UWP 的权限问题，似乎保存文件到任意位置的唯一方法只有弹出一个文件选择框，这与 vim 用户们的习惯大相径庭。最后就还是决定做成一个 Win32 的程序。

这样一来，如何实现 Acrylic Blur 就是个问题了。不过好在当时已经有很多关于 Windows 未公开的 API SetWindowCompositionAttribute 的资料了，所以自己琢磨一下试试也不难。（画外音：Windows 的兼容性负担就是被你们这群人搞上去的😀

当时还有很多采用自绘的方案，但跟原生的亚克力效果还是无法做到一致的。至于如何让整个窗体全都被透明特效覆盖到，这就属于 DwmSetWindowAttribute 和 DwmExtendFrameIntoClientArea 的工作了，这两个 API Aero 的时候就有了，幸亏以前用过，上手速度++。

Winform 还是 WPF？

本来准备使用 WPF，还在 WPF 和 D3D 交互上搞了半天，用了这个看起来没人维护了的 WPFDXInterop，它提供了一个 D3DImage 控件，只要把渲染好的图贴上去就可以了。但是最关键的是用它搞不定透明，如果在 WPF 里通过 WinformHost 的嵌入一个 Win32 控件的话，透明效果又不对。

所以最后我选择直接就使用一个 Win32 的窗体，上面所有的内容全部自己用 D2D 画，反正主体界面也不复杂，顶多就是几个 Button、再加上一个简单的 BoxLayout。至于其他的对话框（比如设置），就直接使用 WPF 就可以了。

1px 的不和谐边框

由于 Windows 10 上窗口周围都有 1 px（设备无关像素） 的边框，当我们的亚克力背景透明度调的比较低时，这个 1px 的边框就会露出来。这个问题实在无解，最后我就暴力地用 vim 当前的背景色不透明地先把这 1px 画上，盖住系统的边框，至少颜色上与当前使用的 Color Scheme 能够统一。如果我们的背景没那么透明，这样的边框就不显眼了。

就是这个黄色边框，其实是为了盖住系统的边框

次像素抗锯齿

这是我一直都没有搞定的一个问题。由于我们窗口的背景是透明的，次像素抗锯齿没办法启用，只能使用灰度抗锯齿。但灰度抗锯齿在低分辨率屏幕上的效果并不是很好。

我还特意去看了一下 UWP 的抗锯齿效果，也不是次像素抗锯齿（放大之后没有明显的红绿蓝边界），但好像要比普通的灰度抗锯齿的效果要顺眼（难道是错觉？）。好在我用 Surface，灰度抗锯齿效果在高分辨率屏幕上还不错，眼不见心不烦😞

连字 Ligature

怎么在 D2D/DirectWrite 上启用连字也花了我不少的时间。连字就是现在很多人喜欢的那种把多个字符（比如->、==）画在一起的那个功能。

要实现连字，首先需要通过 TextAnalyzer 分析输入的文本，得到一组 Glyph 的索引，以及一组 Cluster Map。Cluster Map 里面村的就是 Code Point 到 Glyph 直接的对应关系。比如，如果 Cluster Map 的内容是 [0, 1, 1, 2, 4]，那就代表第 1、2 个 Code Point 对应了一个 Glyph（比如 Ligature 的情况），而第 3 个 Code Point 对应了 2 个 Glyph （比如阿拉伯文上面的各种修饰）。

 Codepoint Index    Glyph Index
       0  -----------   0
       1  -----------   1
       2  ----------/
       3  -----------   2
          \----------   3
       4  -----------   4

最后使用 DrawGlyphRun，把几个 Glyph 一起画出来。如果字体提供了连字支持，那么在 Cluster Map 中就会有所体现。

C++/CLI 做胶水

有时需要跟 Native 的 Win32 API 做交互，这个时候就会感叹有一个 C++/CLI 这样的语言做胶水实在是太方便了。但 C++/CLI 的 Bug 也不少，有时会遇到报编译器内部错误，建议我把 XX 行附近的代码换个写法🤣 现在在 dotnet core 的趋势下，大概 C++/CLI 历史任务也快圆满完成了，可是替任者在哪呢？

关于这个项目的一些回忆大概就这么多了。最后还是要感慨一下，跟调原生 DirectX API 相比， 用 SharpDX 确实舒服很多，这可能跟 C# 的语法糖们也有关系8️⃣。

Redo Build System

发表评论

前一阵子想找一个简单的 build system，看到了 redo，就去研究了一下。一开始还有点迷糊，但最后发现，虽然 redo 看起来只做了一件事（当文件变化时重新执行脚本），但它其实还解决了另一件更重要的事：如何在一个命令式语言中描述结构信息？

声明式语言是擅长描述结构信息的，谁是谁的父亲、谁是谁的兄弟、谁依赖了谁、谁的属性是什么等等。Makefile 就是一种典型的声明式语言，大多数 build system 也都使用声明式语言来描述构建流程（也有的使用了同时掺杂了命令式和声明式的语言，比如 Meson）。

回到一开始的问题，如何在命令式语言中方便地描述这种结构信息？熟悉函数式编程的人大概一下子就会想到使用 Method Chaining:

target("all")
    .depends_on("other_target")
    .source_files("a.c", "b.c")
    .call("...")
    ....;

虽然很多语言都能模仿出这种写法（你甚至可以用 bash 写 fp），但这已经不算是典型的命令式语言的用法了。同时，它仍然是“提前声明”式的做法（即在 build target 之前声明好这个 target 的所有属性、依赖等等），不够灵性。Redo 的做法同时也解决了 Makefile 的一些其他问题，例如依赖的其他 Make 文件是在编译过程中产生的情况、或是 Recursive Make Considered Harmful。

Redo 的做法其实很简单，就是让脚本一边跑，一边收集脚本或文件之间的依赖关系。这是它与其他声明式语法的 build system 的最大不同之处。这样的好处是，build 过程仍然用 bash 描述（比起用 Method Chaining 自然很多），而且依赖关系可以随时添加——甚至在编译结束之后。在命令式语言里看起来这是再正常不过的事了：

# 依赖 $2.c
redo-ifchange $2.c
gcc -MD -MF $2.d -c -o $3 $2.c
read DEPS <$2.d

# 依赖 gcc 生成的头文件列表中的所有文件
redo-ifchange ${DEPS#*:}

稍微跑个题，我很久之前其实也想过类似的问题：如何在 C++ 中描述一个图形界面？这个问题与虽然跟 Redo 半毛钱关系没有，但解决的思路其实完全一样。最后我做到了这样：

这是完全合法的 C++ 代码，扔进编译器就能编过。它描述了 main_form、button1 和 button2 之间的结构关系（父子关系），看起来像是声明式的语法，但仍然不丧失命令式语言的特点。最后只要：

int main()  
{
    yz::app app;
    yz::window* w = yz::ui["main_form"];
    app.exec();
    return 0;
}

就能启动。实现细节请看 https://zhuanlan.zhihu.com/p/24196189

至于如何看待 Redo，我觉得它小众自然有它的原因。一个 build 脚本，目标的依赖关系方面使用声明式语言更容易表达，而每个目标的产出过程是一个命令式的过程。所以路无非三条：可以在声明式的语法中加上点命令元素，或是在命令式的语法中加上点声明元素，或是干脆搞一个半声明半命令式的语言。Make 走的第一条路，Redo 是第二条，Meson 是第三条。

从结果来看，大家明显认为解决目标之间的依赖问题更重要。