从今天开始，Emacs里面可以运行任何你想要的程序 (Linux & Windows & Mac & BSD)

manateelazycat · 2019 年4 月 14 日 04:11

EAF 其实给你控制力, 完全符合Emacs的窗口模型, EXWM 只是把不同应用窗口放在一起, 但是它没法做到两个Windows显示同一个Buffer的内容, 比如 EAF 可以做到两个窗口看同一个 PDF 的不同部分.

因为有了DBus IPC, EAF可以通过 Python 控制 Elisp, 反过来 Elisp 也可以通过 DBus 来控制 Qt 的渲染和任意 Python 代码.

EXWM只是做了窗口管理器的工作, 但是其他非Emacs应用怎么做完全是应用自己的事情, 比如按键和操作, EXWM不会管.

EAF从策略上, 更像是根据Emacs的设计理念去扩展图形化应用, 你可以要求所有EAF的图形应用都使用和Emacs同样的按键去操作应用.

我现在主要都在用Mac, 不知道Mac怎么实现Linux窗口管理器图层合并的技术.

EAF更像一个我个人的设想, 希望告诉 Emacser , 其实Emacs可以怎样去扩展, 达到真正的 live in Emacs.

但是通过实验, 我觉得这个世界上同时精通 Emacs, Linux, Qt, 窗口管理器图层合并的黑客太少了, 目前大多数 Emacser 都不懂 Qt 和 Linux/X11 , 所以 EAF 的发展未来还是靠社区, 而不是靠我一个人.

sluk3r · 2019 年4 月 14 日 04:35

多谢大牛的贡献，现在正需要一个Emacs中打开Pdf的插件

balabooboo · 2019 年4 月 14 日 05:10

严格来说EXWM还是可以介入一点程序的按键，不过就跟大部份的WM一样，用simulation key的方式将键盘输入的某个按键转换成另一个。而程序内部的行为EXWM确实是一点办法都没有。

所以如果我不喜欢pyqt5程序里面的按键绑定的话，我可以在不修改python source code的前提下用elisp把按键改成我自己喜欢的配置吗？

QT还好，主要是不懂X11

另外现在eaf里没有办法handle大小写输入，这在browser里面满痛苦的，具体是什么原因造成这个限制？

manateelazycat · 2019 年4 月 14 日 06:25

因为EAF的Python代码都是自己造的, 你可以任意修改.

现在是按键从Elisp事件转换成Python Qt可以识别的事件, 但是大小写没有处理完, 我最近都很忙, 等忙完了可以看一下.

balabooboo · 2019 年4 月 15 日 11:53

不想直接改source code不是因为Copyright的问题，单纯只是觉得这样有点暴力。

不知道有没有办法做到在emacs 载入eaf的时候，去读一个放在emacs配置资料夹底下的init.py，这个init.py的目的跟init.el类似，只是改成用来配置eaf底下的python插件

manateelazycat · 2019 年4 月 15 日 12:22

明显可以, 但是最近没有太多时间折腾EAF

balabooboo · 2019 年4 月 17 日 05:04

eaf可以分割出两个window来显示同一个buffer，但是我使用的时候发现没办法在不同的window显示同一个buffer的不同部份？当滚动某一边的页面时，另外一边也会跟着一起往下滚，请问这样是正常的吗？

manateelazycat · 2019 年4 月 17 日 07:05

原来可以, 中间版本改了.

esrnevsdf · 2019 年4 月 17 日 07:26

非elisp实现，华而不实

kentch98 · 2019 年4 月 17 日 08:10

talk is cheap，你的仓库亮出来让大家见识下呗

tumashu · 2019 年4 月 17 日 08:11

随意贬低别人的成果是一种不好的行为。。。。

kentch98 · 2019 年4 月 17 日 08:24

挺有自信的，28天前刚入门就能对emacs贡献代码的开发者评头论足了

你对这个社区唯一贡献可能就只有引发大家对痔疮的警惕

tumashu · 2019 年4 月 17 日 08:34

可能这个同学也是新入门，有那种唯elisp的狂热，这个理解，我一开始也有这种思想，估计在 emacs 社区折磨上1年，就会有相对理性的看法，大家就不要就这个话题继续讨论了。。。。

balabooboo · 2019 年4 月 17 日 09:34

有这种想法挺正常的，我用emacs两年了，当看到两个插件一个是elisp写的，另一个是调用外部程序实现的，心里就会主观的想使用elisp版本的（就算elisp版本的比较慢, 比较难用也是如此），有时候强迫症一发作就会干蠢事哈哈

eaf已经是妥协于现实下比较好的方法了。正如大神们说的，不太可能让emacs一开始就是基于gtk, Qt开发的，从github mirror上面看src/xwidget.c这两年的commit上都是些小修小补，也间接的说明了就算emacs可以基于更强大的图形库开发，很多emacs大牛也不希望往这个方向走。就算是现在的GUI Emacs也只用了gtk的非常一小部份(scroll bar, tool bar, menu bar…)。

chunhui · 2019 年4 月 17 日 09:36

你这评论 666:sweat_smile:

balabooboo · 2019 年4 月 17 日 10:05

改的理由是？这个feature很实用的阿, 可以开启同一份pdf然后分屏阅读不同的部份，要比较文档时很方便

这样用起来就不像emacs的buffer了

manateelazycat · 2019 年4 月 17 日 13:56

因为终模拟器和浏览器这种很难做多buffer，所以简单一点做成同步的

LdBeth · 2019 年4 月 17 日 15:17

我可以想到的问題有应用程序会根据窗口寬度调整显示，如果同時显示两个窗口就會冲突，不知道能不能针对这个解決

manateelazycat · 2019 年4 月 17 日 16:05

浏览器和终端模拟器是最极端的两个例子，新建一个窗口其实就是新的内容而不是一个buffer的两个窗口，这两个应用只能用同步

原来第一版是可以混合同步和buffer两种原理的应用，pdf就buffer多窗口，浏览器就同步显示，但是最后框架会更复杂，没有x11 gtk qt编程经验的开发者几乎看不懂

最后考虑快速开发，简化原理都改成同步显示的，更强调eaf应用和emacs本身的协作，而不是让应用自己多窗口状态

同步显示算是一种平衡，冲突只会带来更多困惑

现在工作必须要用到mac，所以最近eaf都没啥更新

manateelazycat · 2019 年4 月 18 日 00:41

因为混合两种模式(同步和 Buffer/Window)会导致架构太复杂, 一般的开发者根本看不懂, 所以最后简化框架设计, 放出去看看大家的反馈.

从现在的反馈看, 如果不是同时精通 Emacs/X11/Qt 的开发者几乎没有能力去扩展 EAF, 即使我文档和Demo都写好了.

加上我最近都在不得不用Mac, 导致我没有时间去改进EAF.