在 邮件 中看到的， 感觉很炫酷啊，能在 buffer 里面运行 Vim 等各种应用程序
图是从邮件链接的博客中复制的，注意图里面这两个框可不是静态图片 
2 个赞
还真把vim跑在emacs里面了👍
xwidget 当初就是用的 xembed，后面发现 xembed 各方面不适合 emacs 才改成了 webkit
而且运行的并不只是 GTK 程序，支持 xembed 都能运行
请问类似功能在 macOS 上有可能实现吗？
这不就是EAF已经实现的嘛，EAF支持windows，linux和macos，EAF可以跑终端，终端里跑vim
macos没有对外提供跨进程粘贴的API
他这个是 in-buffer 的，作为 buffer 中内容的一部分。据我所知 EAF 需要占据整个 buffer。
跑个题，要是能用来让org mode 支持内嵌视频就好了 
EAF理论上也可以实现 in-buffer， 只不过根据 Emacs text buffer 的滚动不断的调整 surface 的 cilp mask 就可以。
不过这种嵌入控件的场景，可以像 popweb 那样 fork 出来专门处理比较好。
这个看起来有意思，不知道性能怎么样
这功能本来就有问题，比如说多个 window 中不能显示同一个 GtkSocket。
支持 XEmbed 的应用也不多，有点可惜
这种会不会实现起来比较复杂？期待 org-mode 下各种多媒体内容混排 
。
GtkSocket和GtkPlug这玩意不适合Emacs“多个View对应一个Buffer”的设计，要不像EAF通过Qt的内置的 QGraphicsView/QGraphicsSence, 要不就要自己用Gtk实现混合器。
不能适应Emacs “多个View对应一个Buffer” 设计的方案， GtkSocket/GtkPlug对于Emacs就是玩具。
如果要兼容EAF的设计，同时支持 in-buffer 设计，改动代码比较大。
如果只是为了 in-buffer 的需求（比如 org-mode) ， 直接 fork EAF来做应该不是那么难。
我用 org-mode 很少，没有开发的动力。
这一套我清楚，我是因为楼主照片中显示的窗口是 GtkSocket 才提到的。 2013 年左右的 xwidget（当时还没有进入主线）就是基于 XEmbed 实现的，后来发现不可行才换为普通的 gtk widget + GtkOffscreenWindow。
我在用EAF浏览器的时候发现，如果不用M-e，直接在网页输入框里输入字母很卡，甚至会漏掉字符，不知道这个帖子方法会不会好点
而且不支持系统输入法输入框跟随光标，希望能整一个类似于emacs控制的原生的QT或者GTK应用。
输入法本质是，输入法进程和Qt或者Gtk窗口通讯， EAF主要是做事件过滤会有点影响，我觉得M-e方式反而方便，可以利用Emacs的编辑插件快速编辑文档。
系统输入法光标跟随理论上可以做，但是我觉得在上面Emacs可以编辑的情况下，跟随不跟随不重要，用Emacs打开后，直接用 emacs-rime 插件更香。
同时，我想和大家分享的是，EAF本质要考虑经济成本和生产力， EAF基于PyQt来实现，跨操作系统渲染的事情Qt做了，快速开发应用和底层库生态Python做了，图形生态Vue.js做了， 这三个基础分别代表图形库、系统底层库和JS生态可以直接增强Emacs, EAF背后代表的三个生态融合到Emacs社区产生的多媒体应用快速生产力才是EAF最大的价值。
像很多社区的朋友建议的那样，用C语言写底层模块，然后用Elisp绑定的方式来做，不是不能做，C语言解决跨平台图形库的工作量非常大，Qt、Python和Vue.js已经存在的生态可以直接用，为什么要从零开始自己造呢？