经过两天努力，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 和分屏功能，感觉完全够用。

debug 了两晚上，就只改了这一行。

WezTerm 实现的 Inline Images Protocol 并不是 iTerm2 原本的版本，doNotMoveCursor 这个参数是 WezTerm 自己加的，iTerm2 没这参数。这本来没啥问题，算是对 iTerm2 扩展吧。

但是！这个参数在不同平台行为不一致，macOS/Linux 不需要 doNotMoveCursor=1，Windows 则必须设置，否则 TUI 会流泪（tearing），我也会哭 😭

#wezterm

Windows 图片预览优化到接近 macOS/Linux 体验了，但还有一些串码的问题，可能和 WezTerm 相关，系统带的 Terminal 没这些问题。

目前应该已经是所有 FM 里表现最好的了，先这样吧。

从 Git 安装尝鲜：
cargo install --git https://github.com/sxyazi/yazi.git

重大更新！

现在预览可以滚动，不仅仅是代码！还包括视频、PDF、压缩包、目录，和 Yazi 支持的所有格式！

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

tokio，tok io
kitty，ki tty

碰巧嘛

Yazi v0.1.4 发行！

- Windows 支持
- 复制文件路径，支持多选
- 自定义 UI 布局
- 更好的文件变动检测，变动后实时更新 mime-type 和 preview
- 新排序方式：自然模式
- 预览可滚动，支持视频、PDF、压缩包、目录等
- 简化文件系统设计，提高整体性能
- 适用于所有组件的帮助，快速查看按键绑定
- 允许自定义 Yazi 配置路径，允许缓存持久化
- 适配 Black Box 终端图片预览

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

什么时候能有自己的窝，每次搬家都好痛苦😖

庆祝！

Yazi 达到了它的第一个小目标，收获了 600 颗星星，谢谢大家捧场！🤩

https://github.com/sxyazi/yazi

晚上刷 Hacker News 刷到了 Yazi，这感觉真的很神奇。。🤣

给 Yazi 做了一个文档站，这个 Showcase 页面是我最满意的。

https://yazi-rs.github.io/docs/showcase

用得 Docusaurus，头一次用，真的挺方便，直接写 JSX，4 个小函数就完成了 Showcase，一共不到 50 行。
（样式参考了 Docusaurus）

重新实现了个 Rust 版的 natural sorting，case-insensitive 比现有的 natord crate 快了 ~6 倍。

起因是昨天 Yazi Discord 有人说最新的 Git 版 打开 /nix/store 变慢了，调查下发现最近加了个 case-insensitive 排序支持，并设置成了默认；而 natord case-insensitive 非常慢，也已经 8 年没维护了。我没想到 Yazi 第一个性能瓶颈是 CPU 不是 IO。

对了，exa/eza 同样有这个性能问题，因为它也是用的 natord，打算找个时间把 Yazi 这个新实现 port 过去。

Yazi 3k啦，记录一下这一刻😆