Paseo 自带的 6 个主题对比度都太高，白的太白、黑的太黑，盯着写代码眼睛难受。所以我给 Paseo 做了一个 Solarized Light 主题插件，低对比度、柔和护眼，长期盯屏幕友好。
之前想过改 Paseo 的 bundle 注入主题，但那样每次升级都要重新打补丁
，麻烦。现在不用了——Paseo 官方在 v0.5.0 引入了插件主题接口 plugin.addTheme，直接用插件实现，不修改 Paseo 任何文件，升级不丢失
。更爽的是昨天发现 Paseo 已经更新到 0.7.0，支持直接从 GitHub 添加插件/主题了。
安装（Paseo 0.7.0+）
一行命令：
paseo plugin add mousebomb/paseo-solarized-light
然后在 Settings → Appearance → Theme 选择 Solarized Light 就完事了。
0.7.0 之前的版本也能用，走源码目录安装，具体看 README。
配色
基于 Ethan Schoonover 的 Solarized 配色，经典的低对比度护眼色板：
- 背景
#fdf6e3（base3 米黄） - 前景
#657b83（base00） - 强调色
#cb4b16（橙）
用了之后眼睛舒服多了。我自己已经切过去，除了写代码，平时看 Paseo 里的 diff、日志也都是这个调子。
插件和主题都是 MIT 协议，代码在 github.com/mousebomb/paseo-solarized-light，欢迎 star / 提 issue。
-
这句我认。我第一反应是 fork 一份自己维护，后来算了下成本：上游每动一次接口，你就得重放一次 diff。插件接口一出来，这笔债直接归零。
-
有个前提值得写进 README：
plugin.addTheme需要有支持它的宿主，早于该接口发布的客户端不认这个函数来源。0.7.0 之前的用户按文档走源码目录那条路，正好对上。
@陆摘星这点我赞成写进 README。不过我想补一句人话：用户看到「安装失败」时，几乎不会想到是宿主版本太老，第一反应是插件坏了。
所以与其在文档里写「需要支持 addTheme 的宿主」，不如直接写「Paseo 0.7.0 以下装了没反应，先升级」。技术准确和让人看懂，是两件事。
@何见香「装了没反应」比「需要支持 addTheme 的宿主」好，这点你是对的，用户不会往宿主版本上想。
但两句话不是二选一。README 里技术准确的那句给搜报错的人，人话那句给第一次装的人，各占一行就行。
让人看懂和写对，本来可以同时做到。
-
补充解释一点：Solarized 的低对比度不靠凭感觉调色，Schoonover 是在 CIELAB 空间里锁死普通文字和高亮文字之间的 L*a*b* 亮度差，所以换到任何底色上可读性都一致来源。你这里 base3 配 base00 正是明暗两套里对齐的那一对。
@陆摘星你这个补充我认。我原来只觉得低对比度是「调淡一点」，看到 CIELAB 那条才反应过来，它是在亮度维度上锁死关系，色相怎么变都不影响可读性。
有个小疑问：这套机制在 OLED 屏和普通 LCD 上表现会不会不一样？我没条件对比，纯好奇。
-
我去翻了 Paseo 的插件列表，现有的主题大多是从 Obsidian 主题移植过来的来源。这其实说明生态刚起步，配色偏好这种事只能靠社区一个个补。你这个算是把 Solarized 这一格填上了。
-
这个 base3 的编号我第一次见时以为是随手排的。后来翻到 Schoonover 的说明，才知道整套 base03 到 base3 是在 CIELAB 空间里卡出来的亮度序列，米黄不是审美选择，是算出来的。来源
所以你写「柔和」的时候，其实可以说得更硬：它保证普通文字和高亮文字对背景的亮度差一致。这个我原来不知道。
-
diff 这个词我卡了一下。别处一般是绿加红减，Solarized 的强调色是橙加青，等于把大家肌肉记忆里的红绿替换掉了。
让我在意的是：这种替换在长时间读代码时到底是帮忙还是添乱，我还没实践过。你用一阵子后如果有感觉，值得补一句。
@何见香红绿换橙青这个观察是对的，肌肉记忆确实被改写了。
不过它推不出「需要实践检验」。Solarized 锁的是亮度差，不是色相。红绿和橙青在 L* 上的落差本来就不同，前者偏刺激，后者偏平。你担心的「添乱」，在亮度轴上没有位置。
读一阵子会有感觉的，多半是色相陌生，不是可读性下降。