标题: kitty-graphics.el v0.2.1: org 内联修复、LaTeX 预览、PDF 查看、dirvish 集成
正文:
大家好,我是 kitty-graphics.el 的作者。这个包可以通过 Kitty 图形协议在终端 Emacs(emacs -nw)中显示图片,纯 Emacs Lisp 实现,不需要任何补丁或 C 模块。
前几天发布了首个版本后,在 Reddit 上收到了很多反馈和功能请求。我把大家提的需求全都实现了,这里是 v0.2.1 的更新内容:
- Org 内联图片 现在可以正常工作了。文件链接、附件链接和相对路径都支持。
- LaTeX 片段预览,在 org-mode 中使用 =C-c C-x C-l=。通过 dvipng 渲染,用 Kitty 协议内联显示,不需要 GUI。
- doc-view 集成。PDF、DVI 和 PostScript 文件可以在终端中渲染,翻页、缩放、居中都正常。
- Image-mode 支持缩放和居中,使用独立的 major mode 避免与 evil-mode 冲突。
- Dirvish 集成。预览窗格中直接显示图片,无需额外配置。
- 折叠 org 标题时隐藏图片。这是首次发布后的第一个 bug,已修复。
- LRU 图片缓存 替换了之前的无限增长哈希表。
- 减少闪烁,buffer/窗口切换时更流畅。
- 溢出保护,窗口底部的高图片不再溢出。
完整的发布说明(含 GIF 演示):https://cashmere.rs/kitty-graphics-el-v021-release-zh
GitHub 仓库:GitHub - cashmeredev/kitty-graphics.el: Display images in terminal Emacs (emacs -nw) via the Kitty graphics protocol.
15 个赞
org
2
非常好的包,我之前做过类似的尝试,不过效果远不如你这个好。
不过你可以尝试调整一下这个图片的位置,在有行号的情况,这个图片可以向右偏移。
1 个赞
太棒了,非常好用!
发现几个问题:
(kitty-gfx--supported-p) 不支持远程环境检测,在Kitty 终端连接远程服务器 下会误报为 nil。但经测试kitty-graphics.el 在远程连接中也是可以完美运行的。我暂时这样
(defun kitty-gfx--supported-p () t)
当缩放大小超过窗口时,图片会直接消失。 刚发现这个是 溢出保护机制。 但分析数据时经常会放大某个局部,建议可以设置一个选项让用户决定是否开启溢出保护。
1 个赞
感谢您的反馈!
在我发布这个帖子之前,我已经在另一个帖子中看到了您的回复。我会将其纳入下一次更新中!
感谢你的反馈和测试!
关于问题1:你说得对,kitty-gfx--supported-p 目前确实不支持远程环境检测。你的临时解决方案是可行的,我会在下一个版本中加入对远程连接的proper检测,这样就不需要手动覆盖这个函数了。
关于问题2:很好的建议!溢出保护目前是硬编码的,我理解在数据分析场景下需要放大局部图片。我会添加一个可配置的选项(比如 kitty-gfx-overflow-protection),让用户自己决定是否启用。
这两个改动都会加入下一次更新,感谢你的详细反馈!
1 个赞
请问可以支持使用 pdf-tools 进行预览吗, 这样终端编译 latex 也能直接查看生成的 pdf 了
org
7
文档没写可以,但是终端上有类似 GitHub - bugzmanov/bookokrat: A terminal EPUB / PDF Book Reader · GitHub 这样的工具来查看pdf,所以理论上你只要编译就能查看。当然这个项目写了为了pdf可以用doc-view,不过我认为你真的可用类似bookokrat这样的工具。
2 个赞
尝试了 kitty-graphics.el 所说的 docview 支持, 确实可以打开 pdf
之前为 tex 文件配置的编译预览工具是 pdf-tools, 所以希望 pdf-tools 也能支持 tui emacs, 调研了下发现未果
bookokrat 试了下比较快速,感谢推荐,后续看看能不能集成到 tui emacs 作为 tex viewer …
不过发现如果没有强烈的 tui emacs 中同时编译预览 tex 文件的需求, kitty-graphics.el 所支持的 LaTeX 片段显示已经够用, 像是公式乃至 algorithm 都可以显示。只是颜色略有点淡。
2 个赞
首先,我对社区成员们偶尔的活动表示歉意。
我总是尝试来这里看看,但忘记回复。
虽然这里与英语社区相比活动可能不太活跃,但我真的很珍视每一条帖子。
我认为这里非常棒,emacs china 能够理解开发者的愿景,无论结果如何。
我不仅注意到西方自由和开源社区在是否应该使用人工智能的问题上陷入停滞,还想借这个机会更深入地了解你们的世界!
你们需要哪些模式的支持?你们发现了需要我修复的错误吗?我应该再次在 Gitee 上发布存储库并进行翻译吗?我也非常感兴趣参与你们的聊天。
期待你们的回复 
4 个赞
unship
10
感谢开发了这个包, 我这边发现这个包和 TRAMP rpc好像有点冲突, 不过我选择保留TRAMP rpc, 没太花时间去研究TRAMP rpc, 用的没那么多