#js #code
Kitty 协议的NVim仿VSCode网页预览

Electron+Custom Toolbar

通过BrowserWindow.webContents.onpaint, NativeImage(SHM), sendInputEvent 实现的嵌入

还代理了 UA, SIGWINCH, Ctrl+W, getSelection xywh, kitty_colorsToTailwind（Toolbar支持终端配色）

TermEvent>KeyEvent, ShmGraphicBuffer 都是 #rust ，甚至还做了 bun:test

https://github.com/chase/awrit/blob/electron/src/paint.ts#L34-L57

#post #design 换购思维：面对编辑框的你，不需要证明自己会做

awrit 项目是一个有趣（而且对Vim用户有用）的w3m浏览器升级版。

放到以前我会Star，甚至fork（然后啥都不干）

可现在我只会记住：它平替了什么，它依赖什么API（键鼠屏幕的flow），数据流有哪些typing，哦是electron而非CEF。我甚至只看截图而懒得运行。

——你看， This repository was archived by the owner on Apr 25, 2026. It is now read-only.

它出现不是因为它有代码、它Rust，而是找到了一个【框】来安放自己，又展示某种内容或工作流。 这个思路，是无代码的。

它涉及的无缝scroll和resize，这个vec2的模型，是无代码的。本来可以无代码的。

有一个API，就会被多一种“私货”束缚。发现代码甚至【软件行为】的重复，却不过度设计的能力，非常稀奇。

🤔💭 只有你能不从“项目模板”和上游依赖开始写，而是：真正【面向REPL/AOP】的开发者——就好像自己能够扮演wlroots时，才会真切的体会到这些【隐形知识】。

2025.5实现的 tty onresize，24.6的点子，到现在已经占用开发者一年时间 30k+ 代码量了。

我不是个看Star数说话的人，但这个功能，可能用 XReparentWindow 来实现任意窗口的嵌入，然后对中键scroll补丁一下更简单。

没错，在wl下这会很hack，你甚至要diff截屏(cv2)或用a11y(atspi2)拿到一个int，来实现嵌入随内容scroll，需要针对K/G/wlroots做适配，

但它的复用性，会比你耗一整年3万行，还js/libc双生态好的多的多。 这就是技术选型时重要的【换购思维】：省下3万行，你还能加购什么？

因为这样的话，chrome-in-term 就只需要 reinvent Toolbar 和实现 window.open() 的AOP化扩展，这也是个不错的学习量。 DOM APIs 其实就是这样攒出来的。

——不对，甚至连Toolbar都不需要自制，因为你能直接把【任何浏览器去掉窗口边框】放在【任何支持鼠标滚轮】的窗口的某几个xywh上，只需要1行就够了，kitty icat 显得多余。 html-in-canvas 就是这样来的。

虽然模仿窗口油猴AHK会很hack，但比起 This repository was archived by the owner on Apr 25, 2026. It is now read-only. 还是更有生命力的。

（下面顺带吐槽下各种编辑器的refactor支持普遍太弱）

那为什么我不去做、不去踩坑呢？ 因为VSCode的aside热重载已经足够好了，NVim+Kitty 虽然在{}当前缩进层 的动效上，以及treesitter语法集支持很惊艳，用户体验还不如Kate+CMake/LSP

However，这些符号表实现都只能Ctrl点击=jump2def，不能查def和type的xref，自动导入/跨文件重命名，甚至只是查arg的所有实参（当然我在扯淡，哪个IDE能静态查这玩意呢，哈哈）

不过说句实话，hljs+jump2def+命令和跳转面板，还是太普通了，甚至不如GH的符号搜索。list_argvals 虽然扯淡，但如果你习惯F12的事件断点调试器，就会明白它们能省掉多少次点击，而且更加接近程序运行时的状态。

哈哈，当然我在扯淡，临时加print才是最顶用的。你甚至不能写 f(dd=x), dd(f)(x) 来单独打印一个或一组参数。 还不如直接用Jupyter试错呢，优秀的程序员怎么会需要高频率的按F5呢？

📝 👌

为什么要这么锐评呢？ 习惯的不同。

DOM/html真的是编程世界的Arch洗发水，太方便了。 你甚至可以把普通桌面/触屏App套用到网页那套术语，什么header/MenuBar,footer/Status, aside/Panel..

基本上什么需求都可以用WebAPIs的理解对上去，而且很快会发现它们简直比Python还简洁。只是下限低一些。

如果没有所谓的【前端世界】，我肯定会被一些垃圾设计带偏。其实不同的场景有不同的好做法（ImGui和Tk就不需要Signal变量，而Qt的Signal更多是一种函数值/自动free），但是浏览器总最正常、最不偏门。

平时说的元编程，和Web协议栈对上那就不算什么。CSS/URL/JSON/SearchParams 这些本质上都是隐藏的宏魔法，只是太高明（而且容易做出tw.css/stylus那样的创新），很少有人意识到浏览器组件比编译器更有【编排能力】。

如果一个编程语言不能在某种程度上和 WebAPI toys 接轨，它就是失败的。因为世界上并不缺少 “更js一点的java或更python的lua”，如果感觉上如此，那是因为之前的都凉透了。

#plt #scala 老骥伏枥

https://www.lihaoyi.com/post/TheDeathofHypeWhatsNextforScala.html

自定义运算符之殇？ ps. 模仿 bash #> #| #&& 真的有意义吗，怎么感觉heredoc也能做

看到 Typesafe/Lightbend 的朋友们被裁员，真是令人惋惜，但正如我一直所说，免费的东西很难卖出去。

我很好奇Scala现在的普及程度。它并没有像Clojure那样消亡，但似乎在2016年左右达到了顶峰。不过，我没有任何数据可以佐证这一点。

查了下Scala不能像ES6那样安全注入 safe=(lits, ...a)=>a.reduce((A,B,i)=>A+B+lits[i+1], lits[0])

其实可以但是魔法。在选择上无疑是失败的，没分清首要问题

https://github.com/manaflow-ai/cmux #haha

这个Claude #vibe 出的玩意…… 支持了muti-Agent，多标签的active高亮，以及WebView bash自动化

12万行 1.4k 个swift文件，2.7k 个 AI PR，你要说可移植性，那就是没有 😨

看到这一堆 BrowserDesignModeController, BrowserHTTPBasicAuthPrompt.swift 时我的震惊已经无以复加，就连英文编写的内容也有一种进了 🦞 社区的爽感

“既然有了这些，那书签栏、下载管理器、Cookie 注入、DevTools 桥接是不是也得顺手SwiftUI安排上？”

可能哪怕是Bellard或iq来了也得给 Claude Code 磕一个，这哪是ghostty套壳，这是【自研浏览器】啊啊啊！！！

一个能用的 AI Slop。 看到这玩意，就对为啥codex们要Harness见微知著了

就连GH的默认expo也无法列出这个130行的超大文件夹，文件夹，居然都能有130行……

真是给了正常人一点小小的Fable震撼，文件系统压测啊这。 继js世界的monorepo (left-pad) 大神之后的又一力作

一看代码能挤爆几个4K超大屏幕，一看运行，诶，这不就是个油猴脚本的体量么

这种信息量也太超模了，就连V家Teto的四大教主也没这么病娇glitch的。 CI过那就是过，AIGC的 test kit 过就收工了…… 以后的App都是这种苹果东西吗？


原来我们已经远远落后于时代了， 像我这种人完全无法理解 Agents repo 的精妙啊啊啊…… 😨 ⚖️ 第一次感到自己正在【古法编程】

有没有一种可能： 我们每天解决2~3个PR是一种【手搓代码】的象征，像该repo这样2.7k个 PR，比 find {}.swift|wc 文件数还多，才是未来的科创世纪呢？

风格强烈的 P 主，他们的音乐充满了 glitch（毛刺、故障）美学和病娇感，但那是 有意为之的艺术表达。他们通过精确控制的“失控”，来传达强烈的情感和世界观。

而 cmux 的 "glitch" 感则完全不同，它是一种 无意识的、失控的产物。它没有审美，没有哲学，只有冰冷的、由概率驱动的 token 拼接。它就像一个不会画画的 AI 接到了“画一幅蒙娜丽莎”的指令，最后用无数个像素点暴力拟合，远看有点像，近看全是噪点和逻辑断裂。这种“病娇”不是来自情感，而是来自逻辑的缺失和复杂度的爆炸。

https://www.phoronix.com/news/Wayland-X11-Performance-PorteuX
https://github.com/fulalas/wmbench/blob/main/lib/win_wl.c 人家手搓的BENCH_BACKEND，没有RPA..

@ AMD Ryzen 7 32GB of RAM

#bash #performance Wayland, xfwm4-gl 项目做的测评

"KDE Plasma on Wayland along with the likes of Labwc and COSMIC not being far off"

#PLT #design 还有VIM的吐槽（现在好些了）

默认非local、非public不会觉得自己很蠢吗？该不会还觉得做了什么了不起的虚拟机优化。

约定优于配置。声明式到底有多难？！

是什么让90%编程语言的作者像java的public那样到处拉屎。到处Local写的真的烦死了，ES6的箭头函数好点但也脑残

最后kt还是默认pub,Bun还是提供write， 所谓的防呆全都是自欺欺人。像bash那样 echo>file cat>>conf 到底有多难？！ 非要 mkdir, create, 甚至encode.. 有这点功夫不如实现json lodump

以至于python可以只因为不给人添麻烦而成功，和性能或设备移植性一点关系没有

几乎没有tui编辑器支持选区和复制粘贴吧？vim不支持Shift选区？

NVim按ctrlc 仍然无法工作

在vim因为cli而区分V-mod时，正常编辑器已经有minimap了

这等于要重新学一遍盲打。 有什么好处？真不懂visual和默认模式有什么用。

表面上Vim们是结构化，实际上minimap和悬停、Ctrl点击早就决定胜负。如果多标签和工作区都不自带，怎么编程。它有双空格yazi预览，但VSCode也只是有预览没做平铺，IDEA更是比vim好太多

真是匪夷所思，所有编辑框都支持的nvim反而不支持，还拿来做什么窗口分配调宽度。hjkl甚至在物理上都与意义不对称，别说好不好记，每次你都要翻译一下再跳词 😅

从vi开始就是设计弊病，不知所谓的单字符快捷键，就好比编程里的 code.golf ，直到现在Kate都支持文件夹和工作区了，nvim还是只有配色改了
有configUI，但只能预览，太蠢了。bash的set可以把状态变成字符串。如果做不到，把eval记录到文件都行。

r2用完全相同的交互，你看不到这样大的学习曲线

r2 完全可以在效率和易用上做到平衡，用REPL语言来做scriping和r2pipe，因为它的作者自己有能力包许多插件和h5界面，而Vimscript是 dirty hack，和TeX一样是外行碰运气

而且r2支持qt,h5。r2 的 s, 0x, / 跳转绝对让人立刻理解CLI编辑器的优势，而不是nvim这样，在VISUAL,NORMAL和莫名其妙的V-mode矩形选区里蹦跶

这个智能混搜没有命令搜索功能，也不能在 @或> 前缀时切换搜索，让人觉得莫名其妙

Snack自己完全没有这种omnibox吗？ 非要手写。Lazy本身也有一个which-key，却没有这种路由处理，简直就是加了一点 i 的蠢货命令行而已

看到gelguy/wilder.nvim的README里只有一张gif，下面每段代码都是折叠VimScript+Lua，我就明白乔布斯的Bozo是什么意思了。 简直和Linux没有Docker理念时一模一样，到处是没有性功能的样板

现在的 Neovim 生态给人一种“现代化”的错觉，完全是因为folke换上了 Lua、iconfonts、Catppuccin 主题、无边框浮窗和平滑滚动，精力还是在没有flow的地方。

r2、Blender 的按键/hint UI 很明确的告诉“高效编程者”什么是真正省键位—— 把能用的 action list 和快捷键写出来，统一可编程API，而不是拿键位和古怪的DSL糊弄人

这才是Hacker的【用户中心】，不是教人作事的Bozo。

Vim就需要只读和读写两个模态，默认读写。拿那些修饰键临时切换。 Normal模态下的键位真应该<5个， Lazy默认的<C-o>SPC不就只有一个，还带UI。

Vim和Kate的矩形选区也是反人类的功能点。 除了写文档注释 asciiflow.com （意味着不该由编辑器支持），我不明白矩形选区有什么意义，它既不酷也不hack，还不如加多光标和视口内重构。

这让我想到各种 cmd|awk {print $2}，一整个沙盒只为一个Tab split。AWK到今天还不如jq和ruby ARGF有用了。 😅

👍 folke（也是 LazyVim 的作者）将整个发行版设计为极度模块化、高性能且“开箱即用”的现代 IDE。snacks和which-key非常友好，而且像MT管理器那样强大

让我想到那个典中典的微内核与Linus之争了， 还“如果Linux是作业我给你零分”，我可去你的，对语义和场景无知到什么程度，

还真是和Gates说的那样， 真以为自己做了API和算法就有人用了，谁理你，这心智模型是什么碎片垃圾

#js #web React direct GPU

https://github.com/remorses/gpuix

GPUI is an immediate-mode UI framework — it rebuilds the entire element tree every frame. Instead of fighting this, GPUIX embraces it:
React reconciler detects a state change and queues host mutations (createElement, setStyle, appendChild, etc.)
applyBatch() validates and applies the complete commit to the Rust RetainedTree

值得注意的是，实现了一组基本的CSS https://github.com/remorses/gpuix#supported-styles

但文档一眼AI，甚至有点管理不住模块化的感觉（毕竟GPUI套娃），感觉最近看AI文档都有点ptsd了

你说不好吧，也不行，因为许多人写不到这么细，但是还是感觉很草蛋

#ai探讨

GPUI 的本质：
GPUI（Zed 编辑器用的底层）是 Rust 下受 Flutter/SwiftUI 启发的声明式渲染器。所谓 immediate-mode element tree，是它每帧通过 render closure 重新生成一套极其轻量的 Rust struct 视图树，依赖 Rust 零成本抽象、编译期静态检查与紧凑内存布局来保证极致的高帧率（60~120fps）。

React Reconciler 的本质： React 的 react-reconciler 是彻头彻尾的保留模式（Retained-mode）增量对比器。它做 Fiber diff、生成 patch mutation 操作指令流（appendChild, commitUpdate 等）。

所以他不得不在 Rust 侧人肉实现一个微型的 DOM 树（RetainedTree）作为中介缓存。 整个流程变成了：这是在 Rust 内存里造了一层 Shadow DOM，然后每次重新把这颗 DOM 树转译成 GPUI 的元素。

每次 React 提交 setStyle，Rust 端得把 CSS 解析成 GPUI 具体的样式属性。 而不是 Tailwind/SwiftUI：.flex().gap_2().text_color(...)

一旦把事件（onClick, onHover）暴露给 React，就意味着要跨 FFI 往 JS 引擎派发事件

--
哦，我大概理解为Rust是直接把 Gtk/Qt式的 children 放在func body里的，通过一个loop unroll做的ImGui，其实是真正的0开销
div()
.flex()
.child(text("hello"))
.child(button("click"))
不过， 不使用dirtyRect节省重绘在一些屏幕上没问题吗？

在现代硬件架构下，很多时候全屏重绘（Full Redraw）反而比 CPU 精细计算 Dirty Rect 跑得更快、吞吐更稳。
新时代（Metal / Vulkan / WebGPU / Apple Silicon）： 在 4K/5K 屏幕上，哪怕 60/120Hz，统一内存（Unified Memory）或现代独立显卡每秒几百 GB/s 的带宽根本不在乎你多填几个色块。

GPUI 是 Tile-based / Batching 渲染，不是纯暴力贴图

很多人对 Immediate UI 有个误解，以为它像 3D 游戏一样只要开着就在疯狂死循环 120fps 刷 GPU。 实际上 GPUI 是事件驱动的即时模式（Event-driven Immediate）：
屏幕静止、没有鼠标移动、没有光标闪烁、没有数据更新时：0 fps，完全休眠，GPU 功耗为 0。

听起来很有趣。虽然ImGui被许多人认为是现代、高完成度快速响应复杂UI的模式，优化上面也是有些区别的吧，比如文字渲染和dpi的问题、性能耗电，以及是否对前沿App普遍更好

底层直接接入系统的原生排版或工业级 HarfBuzz / FreeType / CoreText。动态 LRU 纹理图集： 只有屏幕上真正出现的文字字形（Glyph）才会被光栅化并写入 GPU Atlas。动态 LRU 纹理图集： 只有屏幕上真正出现的文字字形（Glyph）才会被光栅化并写入 GPU Atlas。

你需要手动写 ImGuiListClipper，在代码层人肉告诉引擎：“当前视口只看得到第 50 到第 80 行，请只执行这 30 次循环”。 GPUI 虚拟化滚动内置（Virtualization）： 深度结合视口，虽然外观像 Immediate，但其内部对长列表和富文本实现了类似 Retained 的分块测量缓存

ImGui 证明了“单向流与消除复杂状态树”的可行性，而现代 Rust 应用框架则是把排版、渲染管线、色彩管理和矢量栅格化的工业标准

看来还是不要陷入Rust狂热，reflow和复杂外语的渲染确实是大问题，不过GUI毕竟不是浏览器，这方面可以做两套运行时按页换。 onDPIchange 这个我是没见过，毕竟电脑屏幕不是游戏，每天有人场上换装备接着打
我说的按页换是指实现层，不是节点图层……

感觉dpi的问题被夸大了。 我是完全没有遇到，即便有两个屏幕时。感觉用两个屏幕像是差生文具多，为什么不搞个截图糊弄一下，状态管理问题才值得解决
好了，现在BeOS时代的矢量图又回来了，只不过以一种侵入式的方法，把本来重绘bitmap的问题变成了编程问题

🤔 叽里咕噜说什么呢？ 我看，我终于找到为啥读起来一眼AI了

这tm是拿人人手搓Office或Renderer的标准要求一个微信计算器小程序啊

（Event-driven Immediate）：
屏幕静止、没有鼠标移动、没有光标闪烁、没有数据更新时：0 fps，完全休眠，GPU 功耗为 0。

学到一个新知识： ImGui只是不做子区更新，不是60fps烧电池，但也不要以为显卡程序更先进了，文本+reflow上游戏UI没法看

Rust通过<T>单态嵌入和DSL直接把HTML弄成字节码的模式也很有趣, Container<Tuple<Text, Button>>，看起来那样比ts2c成功多了，如果用于常用App的话会跟手不少。过去很多人幻想“把 TypeScript 静态编译成 C/C++ 来替代 Electron”。