emskin: 把 Emacs 放进一个 Wayland 合成器里，让任意程序（浏览器、终端、视频播放器等）都能像原生 buffer 一样嵌入 Emacs 窗口。

loyalpartner · 2026 年4 月 11 日 22:33

这几天和懒猫大佬的灵感碰撞下，利用空闲时间写了一个 wayland 合成器，让任意程序（浏览器、终端、视频播放器等）都能像原生 buffer 一样嵌入 Emacs 窗口。

不挑桌面，可以跑在 x11 和 wayland 桌面，目前对 pgtk 版的 emacs 体验较好， gtk3 可能还存在些许问题

Arch Linux 可以通过 yay -Sy emskin-bin 安装

目前实现的功能：

任意程序嵌入 — Wayland 和 X11 程序均可嵌入
窗口镜像 — 同一程序显示在多个 Emacs 窗口
输入法支持 — 共用宿主输入法，输入法精确定位
剪贴板同步 — 主机与嵌入程序双向同步
启动器支持 — rofi / wofi 等可直接使用
自动焦点管理 — 新窗口自动获焦，关闭后自动回退

目前存在的问题:

合成器没有对 dbus 路由，有些依赖 dbus 的程序可能会跑到合成器外面

ginqi7 · 2026 年4 月 12 日 01:50

macOS 用户流下了羡慕的口水。

吐槽一下 banner 蓝色图像 ai 味太浓了，还有 gemini 的下标。建议让 ai 给换个配色。哈哈。

ningxilai · 2026 年4 月 12 日 02:03

1）如果使用sort-tab一类涉及tabline的插件，上方的窗口栏似乎也就没有了什么必要，我没看到el文件中有那里可以可以关掉它，同样，如果你定制了header-line，看起来的效果也不好，应该对这种情况有些处理（就像eww）。

2）在我的hyprland上，如果在使用了emskin的情况下启用eaf应用，emacs不会给出任何应对，也不会怎么卡顿，这是eaf的问题么？

manateelazycat · 2026 年4 月 12 日 02:12

手动点赞，这个项目做好了，下面这些项目可以退出历史舞台了：

EAF，所有EAF能做的事情，这个项目都可以做的更好
sort-tab，可以用外部程序实现更酷炫的标签栏
holo-layer, 窗口边框、输入的power mode效果等特效都可以在 wayland 合成器里面做的更好
blink-search, 这种悬浮搜索的都可以做的更好，外部 rust 程序做搜索，要比 ivy 快100倍
悬浮终端， NeoVim 那种悬浮终端，包括半透明模糊效果兜可以做的非常酷炫
终端，外部终端融合进来，所有Elisp开发的终端都可以退出竞争了
浏览器，找一个命令行浏览器，全键盘操作，想象多爽？
文件管理器，专门用 rust 给 emacskin 写一个键盘操作文件管理器，各种文件预览都可以做
pdf阅读器，pdf、epub这些都可以重新写一个全键盘操作的命令

无穷的想象，Super EAF项目的终极目标也不过如此，加油，等我这段时间公司项目开发完了，我来加入开发

loyalpartner · 2026 年4 月 12 日 02:46

目前只是一个很demo 版本，感谢提出意见

顶部的 tab 其实是 emacs 的 frame ，目前是超过一个frame bar 才会显示， emskin —help 有个参数可以控制是否显示bar，后面会做成 elisp 变量
eaf 应用暂时没做适配，晚点我看看具体撒情况

loyalpartner · 2026 年4 月 12 日 03:30

， gemini 生成的这个 logo 我觉得挺好看的，右下角的 Gemini 可以抹去

tianzhushan · 2026 年4 月 12 日 04:37

大佬，mac下有目标没？

loyalpartner · 2026 年4 月 12 日 04:45

目前只能在 linux 里面跑，技术路线决定了 mac 无法支持

loyalpartner · 2026 年4 月 12 日 05:03

这个要 eaf 增加 emskin 桌面的检测，还有 emskin 要针对 eaf 窗口的桌面做专门的按键路由

我把这个加到 todo，不过适配的优先级可能会放低， eaf 正准备用 emacs dynamic module 重构一轮，等重构完再去做兼容处理

github.com/loyalpartner/emskin

EAF (Emacs Application Framework) app integration

已打开 05:06AM - 12 Apr 26 UTC

loyalpartner

## Summary Add support for running EAF apps (browser, pdf-viewer, etc.) inside …emskin compositor. ## Background EAF creates PyQt6-based application windows that need to be managed by the compositor. Currently EAF has two display modes: - **X11 reparent mode**: embeds Qt window into Emacs via `setParent(emacs_xid)` - **Wayland stay-on-top mode** (pgtk): uses `BypassWindowManagerHint` + `WindowStaysOnTopHint`, manages focus via GNOME Shell DBus Neither mode works with emskin — reparent doesn't apply (emskin manages windows via IPC), and BypassWindowManagerHint prevents xdg_toplevel creation so the compositor can't see the window. ## Required Changes ### emskin side 1. **`spawn_child`**: set `XDG_SESSION_DESKTOP=emskin` so EAF can detect the compositor 2. **`emskin--on-window-created`**: detect existing EAF buffers (`eaf-mode`) and attach `window_id` to them instead of creating redundant `*emskin:*` buffers ### EAF side (upstream PR needed) 1. **`eaf.el`**: add `eaf--on-emskin-p` detector (checks `XDG_SESSION_DESKTOP`), handle in: - `eaf--get-frame-coordinate` → return `(0 0)` (compositor manages positioning) - `eaf--get-titlebar-height` → return `0` (no titlebar) - `eaf--topmost-focus-change` → skip (compositor manages focus) 2. **`core/view.py`**: in emskin mode: - Window flags: `FramelessWindowHint` only (no `BypassWindowManagerHint`) - Skip `reparent()`, `try_show_top_view()`, `try_hide_top_view()` 3. **`eaf.py`**: in emskin mode, `update_views` should not destroy/recreate Views on geometry changes (use `buffer_id` as key instead of `view_info` string) ## How It Works 1. EAF creates a View (QWidget) → normal xdg_toplevel (no bypass flags) 2. emskin detects new toplevel → sends `window_created` IPC to Emacs 3. emskin.el finds the existing EAF buffer, attaches `window_id` 4. emskin positions the window via `set_geometry` IPC based on EAF buffer's window position 5. View is created once and never recreated — compositor handles all positioning ## Key Issues Solved - `BypassWindowManagerHint` prevented xdg_toplevel creation - GNOME Shell DBus calls in `eaf--topmost-focus-change` and `eaf--get-frame-coordinate` caused errors/timeouts - `update_views` using `view_info` (with coordinates) as dict key caused infinite create/destroy loop on geometry changes - EAF buffer vs emskin buffer conflict — need to reuse existing EAF buffer

loyalpartner · 2026 年4 月 12 日 05:16

能发一张不用 emskin 启动的 emacs的图片吗，我对比看看效果，现在我不知道哪部分是 sort-tab , 还有窗口左右间距则呢吗这么宽

ningxilai · 2026 年4 月 12 日 08:32

我在early-init中设定了窗口的留白，所以宽度才这样大，至于sort-tab，看到|README.md|emskin|没有？那就是sort-tab

galoistom · 2026 年4 月 12 日 11:40

感觉这个思路很有前途啊，就是这个可以像emacsclient一样和跑着的emacs连起来吗

godblessfq · 2026 年4 月 12 日 11:55

看起来像一个窗口管理器，这个和 ewm 的区别是什么？“ezemtsov/ewm: EWM - Emacs Wayland Manager - Codeberg.org EWM is a Wayland compositor that runs inside Emacs.”是不是没法支持多个显示器？如果不想放弃 Emacs 窗口管理器，能不能整合进 ewm 里面，做一个 EAF 的平替？

“合成器没有对 dbus 路由”，这个 Emacs 能和系统进行 Dbus 交互吗？主要是这两个 elisp 函数 (dbus-call-method dbus-register-signal) 能不能用？这是 Emacs 和系统共用输入法的依赖（GitHub - QiangF/imbot: an input method management bot for emacs · GitHub)

看来 wayland 的时代真的已经来了。

loyalpartner · 2026 年4 月 12 日 12:02

有些程序启动的时候会先用dbus 查一下是不是已经有实例启动了，如果已经有外面跑的实例，这时候就会绕过合成器，直接渲染到宿主的显示服务

比如： deepin-editor

后期的解决方案是：在合成器里面启动一个用户级别的 dbus 会话，通过一个 dbus router 做路由，这样这类程序就能跑到合成器里面了

godblessfq · 2026 年4 月 12 日 12:04

嗯嗯，是 Emacs 自身和容器外面的 fcitx5 用 Dbus 通信

godblessfq · 2026 年4 月 12 日 12:06

这个必须要 wayland 吗？我现在用 emacs EXWM 窗口管理器，能不能里面跑一个这种容器？

loyalpartner · 2026 年4 月 12 日 12:07

x11 和 wayland 桌面都能跑， emacs 尽量用 pgtk 的版本

godblessfq · 2026 年4 月 12 日 12:08

现在最想要的就是把一个正常的 Firefox 放到 Emacs 里面，一旦实现了，很多项目都可以退休了，比如 GitHub - emacs-os/embr.el: Emacs is the display server. Headless Chromium is the renderer. · GitHub

loyalpartner · 2026 年4 月 12 日 12:10

那可以试试，理论上exwm 跑 emskin 问题不大

godblessfq · 2026 年4 月 12 日 12:19

这个项目体现了从基础上解决问题的力量，下一步看能不能和 AI 结合起来，实现 Emacs 对第三方 App 显示内容的理解，从简单的快捷键交互，到对现实屏幕控件的操作，从这个角度看，linux 和 windows 好像还是有差距，一个例子如：GitHub - Hello-Mr-Crab/pywechat: 仍然可用的微信RPA！支持4.0系列微信pywechat是一个基于pywinauto实现的windows桌面微信自动化操作工具，基本实现了PC微信内置的各项操作。 · GitHub 咱们需要更多的底层设计