加载失败
reMarkable 2（电子墨水手写平板）本质上是一台跑 Linux 的设备，很多人会通过 SSH 折腾它，把原本只能记笔记的机器改成更开放的实验平台。这个 Show HN 展示的是在它上面跑的手写 Clojure REPL：用户写下表达式，系统识别后再把结果渲染回屏幕。讨论之所以集中在延迟，是因为 reMarkable 的官方笔记程序 xochitl（官方笔记/界面进程）把 notebook 更新到磁盘很慢，常常要十几秒，这让“实时”交互天然吃亏。评论还把话题扩展到直接驱动 framebuffer（屏幕帧缓冲区）、绕过 xochitl 的 Qt app，以及 appload、xovi、ReManager 这类帮助安装自定义应用的工具。
不少评论把它视为典型的“因为能做所以去做”的项目：虽然用途不实用，但把 reMarkable 2 变成手写 REPL 本身就很有趣。有人直接把它类比成“magic mirror”式实验，强调这种设备最迷人的地方就是可被随意折腾。也有人觉得手写博客和 Clojure REPL 的组合很漂亮，哪怕日常不会真的拿来干活，也依然值得玩。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
讨论里最明显的槽点是延迟：从笔停下到屏幕给出结果要等十几秒，体验很难称得上“实时”。评论者希望拆解这 14 秒里到底是设备保存、识别、启动/停止逻辑还是求值占了时间。后续说明指出，主要瓶颈在 reMarkable 自己把 notebook 写入磁盘太慢，xochitl 往往要十来秒才真正更新文件，因此问题更多出在系统流程而不是 REPL 本身。
技术讨论集中在如何更直接地控制 reMarkable 2 的屏幕和系统。有人解释电子墨水屏不是普通 LCD，像素翻转需要多帧，而且还要依赖特定的 waveform/wbf 规则；因此直接驱动并不轻松。常见路线包括 hook xochitl（但对更新很脆弱）、直接写 framebuffer、走 streaming API 把屏幕送到远端服务器，或者干脆自己写 Qt app；waved、Zig 重写、Rust 方案以及 appload/xovi/ReManager 这类工具也被提到，说明社区一直在尝试绕开官方限制。
有人对这篇手写博客本身很感兴趣，尤其想知道内容是不是直接在设备上写出来，以及链接是怎么嵌进手写文本里的。回复说明工作流已经从 PNG 转到 SVG，并用更方便的方法计算链接坐标。这个细节说明项目不只是一个 demo，而是把手写、排版、超链接和发布流程都串起来了。
另一条支线讨论如何把识别和扩展尽量放到本地。有人建议用 PaddlePaddle OCR 做手写转文本，认为速度足够快，甚至可能比远程模型调用更实用。也有人问 Supernote Manta（带 plugins API 的电子墨水本）会不会更适合这类扩展，同时评论还争论 reMarkable 的维修性和 USB-C 口可靠性：有人推荐更可修的新版，有人吐槽接口脆弱，也有人说自己用多年仍然正常。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
REPL: Read-Eval-Print Loop，交互式执行代码的环境，输入后立即求值并返回结果。
Clojure: 运行在 JVM 上的 Lisp 方言，这里用来实现手写交互式编程。
xochitl: reMarkable 的官方笔记/界面进程，很多显示和笔记流程都依赖它。
framebuffer: 屏幕背后的帧缓冲区，直接写它可以绕过部分上层 UI 进行显示控制。
e-paper / E-ink: 电子墨水屏，省电但刷新慢，所以实时交互会明显受限。