分享个 webkit.org 暗色图片处理方式。

如果只是 filter: invert(1)，会导致图片除了黑白部分的其它颜色，发生异变。

上次读 WebKit 博客，发现暗色下图片显示也很自然，研究了下他们是自己写了个 SVG filter，只反转黑白色度，红绿蓝尽可能保持。

实现方式见回复 ⬇️

#svg #darkmode

https://sxyz.blog/nvim-async-formatting/

目前探索出的最佳格式化方式，如果有更好的欢迎留言赐教😆

#blog

macOS 安装后广告标识符是打开的，通过以下方式彻底禁掉它，并退出广告追踪：

defaults write com.apple.AdLib forceLimitAdTracking -bool true
defaults write com.apple.AdLib allowApplePersonalizedAdvertising -bool false
defaults write com.apple.AdLib allowIdentifierForAdvertising -bool false

#macos #privacy

最近才发现这个选项，设置后可以 ⌘Q 退出 Finder，退出后就不会再在 Cmd-Tab 占多一个 icon。

defaults write com.apple.finder QuitMenuItem -bool true && killall Finder

我喜欢退掉所有当下不用的 app，保持简单专注，并且大部分工作都在 terminal 完成，因此这个选项对我挺有用的。

#macos #finder

换到了 joshuto，它是 ranger 的 Rust 替代品，终端下的 vim-inspired 文件管理器。

之前一直在用 ranger，但 ranger 实在太慢了，最后一个版本还在 2019 年。把 joshuto 配好用了下就再也不想回去了。

我的配置：https://github.com/sxyazi/dotfiles/tree/main/joshuto

#joshuto #tui

之前在一个群里聊到AI绘画的时候有人说技术本身是中立的云云。回应「哪有什么技术是中立的」之后捅了马蜂窝了，有人说菜刀砍人不能怪菜刀，说我用全称命题否决所有技术的中立性等等。

这里的问题不是哪些技术是中立的，而是中立这个概念是随着人的观点和时代流变的。「中立」不存在，笨蛋。

台湾有台湾的蓝绿和相应的中间地带，美国有美国的，但这两个中间不是同一个中间，同一国家的中立倒推几百年也有很大差别（奥弗顿之窗）。假如我的意识形态是人应该回到部落状态以最原始的方式生活，那一切技术进步都隐含着一种对进步的未来的设定。这样的话自然可以全称地说所有科技都是不中立的。你可以驳斥这种说法极端可笑，但是你不能为你的中立找到一个可靠的支点，你一旦去叙述什么是中立，就是在构造一种意识形态，而不是到达中立本身。

一个看起来很中立的情况，假如我是天才科学家在芯片上发明了一个很棒的结构，而且对制程要求不高，于是被世界广泛采纳。这看起来不带有任何偏向色彩。但是有些人并不这么认为，他们认为现在消费数码正在用更快的指标诱导人计划报废明明用起来没问题的现有设备，实际上对普通人来说设备的性能过剩了，产生了大量电子垃圾往第三世界倾倒云云。相对于追逐更高性能，对于模块化，可维修，可重复使用的需求被刻意忽略了。我可以辩护说我作为研究者和之后产生的消费行为无关，但是科技公司对技术的甄选和包装推销，以及市场对科技的采纳确实可以说选择性的，到达我们普通人身边的技术或多或少蕴含着一种塑造我们生活的期许，而任何这种期许都可以且应当被审视。而有些技术诞生开始隐含的期许就会让许多人感到不适，比如敏感词识别，步态识别，检测维吾尔人的模型，舆情分析…而另一些技术可能就只有小部分人感到不对劲，对大多数人来说看起来就是中立的，要是忽略那小部分人直接宣称这就是中立的就仅仅是在强迫别人遵循你的中立而已。

于是根本没有什么中立，就更没有什么技术中立了。

最近有机会摸了下 rua st，尝试写点使用心得：

- Rust 核心是 ownership，这迫使（也应该）在设计时更多考虑资源 domain 边界，很有 DDD 那味儿

- 如果饱受 ownership 折磨，那一定是设计问题。比起用很 fancy 的招式，比如 Rc<RefCell<T>>，不如下沉并重新审视整个设计

- Rust 没想象的难写，如果允许一些重复代码出现。但若受不得重复， closure/macro 始终是你的朋友

- unsafe 不是不安全，只是回归常态。在可控的前提下，能极大削减循环引用的复杂度

- 曲线才是捷径，有时间接比直接更好用

#rust #learning

感觉 Rust move 这个 keyword 应该像 pub fn 这些简化成 mov，主要：

- move 太常用了，一旦 keyword 别的地方就用不了，主要函数名
- 可以用其它词代替 move，但总有点词不达意
- 函数名可以 mov，但其它地方又会出现 move_files，不太协调，当然也可全部 mov_files，怪怪的

#rust #learning

Kitty 终于支持背景模糊了，配置完漂亮多了，之前只能设不透明度，看久还挺单调的。

https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.background_blur

#tools

开个新坑：yazi，一个新的终端文件管理器，使用 Rust 开发，基于 async I/O。

目标是同时兼顾性能、功能，核心部分完全 Rust 实现，减少外部依赖以避免性能瓶颈和体验劣化。

https://github.com/sxyazi/yazi

#tools #oss

周末把 yazi 的 Input 组件重构了下，按词移动，visual mode，undo/redo，yank/paste，这些基本功能都有了。还支持了 CJK 字符渲染，和长内容滚动。

头一次实现一个 terminal 的编辑器，踩了挺多坑，不过还算有趣。

尝试在 OrbStack 里跑 Arch Linux + GNOME，使用 RDP 连接，成功了。

感觉比普通虚拟机快一点，谢谢 @XYenon 姐姐浇浇，晚上能给 yazi 调 Überzug++ 了。😇

经过两天努力，Yazi 现在支持在几乎所有终端显示图片了。

https://github.com/sxyazi/yazi/pull/12

#yazi

Rust 的 sixel-sys 已经 6 年没更新了，晚上读了下 VT340 文档发现挺简单，就自己实现了个最简版本。

不到 40 行，目前够用，后面再支持下透明图片和指令压缩就完美了😋

#sixel #vt100

测试图片预览功能，发现 Hyper 不工作，但它是支持 Sixel 的，debug 发现 ioctl 系统调用返回 ws_xpixel、ws_ypixel 都是 0，yazi 依赖它计算图像宽高。

似乎 node-pty 问题，他们修复前，图片预览在 Hyper 不可用，我不知道怎么不依赖这些值渲染图片。

这就是跨平台吗，有一个平台拿不到值，干脆所有平台都返回 0。😅

https://github.com/vercel/hyper/issues/7375

#hyper

最近照着 React 的思路写 tui，有点新体会。

ratatui 作为一个 Rust 的纯 UI 库，只负责渲染，状态完全自己管理，这使得状态/逻辑和 UI 分离很容易，以后迁移到其它 UI 库很简单，没有强绑定，no strings attached。

状态/逻辑部分可读、可写，UI 渲染时“只读”（这点很重要），这是 React 单向数据流、副作用的概念。不应该在渲染途中改变某个状态，否则会产生副作用（side effect）。同时状态的单向流动也很重要，如果状态变化 -> UI更新，就不能反过来 UI更新 -> 状态变化，违反这个就构不成“只读”的条件。

因为所有状态在渲染期间“只读”，不存在数据争用，可以很廉价的在多个 thread/coroutine/... 共享，因此很自然 React 就出现了并发渲染（Concurrent rendering），这是水到渠成的。

同时由于状态不变，达成部分函数式特征，不管水合还是测试，确定性都很重要，并且（局部）渲染结果也可以很容易被缓存和复用。这个“只读”真的很重要，一旦有了确定性，能做的事就太多了，最简单我能想到的比如渲染可中断，合并多个（不同）渲染，等等。

状态变化 emit!(Render) 一下完事，我不太敢想象使用 reactivity 思路开发需要付出多大努力，tui 也并不像 browser 提供各种工具监测每个状态变化，而自己实现一套可能性能反而更差，没法和 browser 长年累月的优化和各种黑魔法媲美。

不过好处是 React 这套不强依赖特定平台特性，所有平台适用，且容易移植。有些人写 React 思路转换不过来，可能是因为他们一直都在以“可读可写”、“指针在手，天下我有”、“指哪打哪”的模式开发应用，没有做更细微的状态边界划分，就像一个类全是 public method。（这句太得罪人了，先提前谢罪🥹

#react #tui

看到自己写的东西，对别人有用，真的很开心啊😌

Yazi v0.1.3 发布啦。这是有史以来最大的一次升级，22 个新功能，9 个错误修复，5 项性能提升。

谢谢每位贡献者为让 Yazi 变得更好所付出的努力！

https://github.com/sxyazi/yazi/releases/tag/v0.1.3

--------
对了，现在 Yazi 有群了。

Telegram Group (Chinese mainly): https://t.me/yazi_rs

Discord Server (English mainly): https://discord.gg/qfADduSdJu

Windows 图片预览终于调通了。

下个版本 Yazi 能直接在 Windows 运行，不需要 WSL，目前还有一些 Windows 所特有的问题需要解决。

谢谢 @gplane 大佬的 PR https://github.com/sxyazi/yazi/pull/44

为什么说 tmux 这类 multiplexer 是性能杀手？除了 CSI 序列需要被翻译两遍外，我还找到另外一个原因：

昨天翻 wezterm 代码，发现为了适配 tmux 和 ConPty 被逼的只能加 sleep。ConPty 是 Windows 为了向后兼容在真实 TTY 和 Terminal emulator 加得一个兼容层，原理和 screen/tmux 类似。

不过 Windows 这个属于系统性设计失误，Windows terminal devs 已经承认这点，它不仅导致性能下降，还导致了像 Kitty、Sixel 这些图像协议/格式完全没法工作 —— 作为 multiplexer，它只向用户终端转达它认识的那些转译序列，像 Kitty、Sixel 这些它并不认识，因此根本没机会到达终端模拟器进而显示成图片。

虽然有让 ConPty 支持 Sixel 和直通真实 TTY 的提案，但都没啥进展。对了，我已经抛弃 tmux 很长时间了，使用 kitty 自带的 Tab 和分屏功能，感觉完全够用。