Emacs 29 中 Xinput2 与 EAF 的兼容性问题

因为你欠考虑(在未来可能会)直接push的代码就逼着其他人不用一整个大feature吗?你为什么不能选择三思而后行呢。

说到底,你就不能正面回答一下上面的问题吗?能不能收起自己的ego?

你现在没push没问题,你只是propose了一个方案,于是懒猫在这里对你的proposal提出了意见和疑问,可是你避重就轻回避他提出的疑问,多次强调代码不会改变我没时间修根本问题不想用就别用,你好歹听一下别人的意见好吧。

我已经正面回答了上面的一切问题。

Core Input 代码都没有遭遇到改变,EAF 可以像往常一样正常工作,而 Emacs 开启 XInput2 时会改变内部处理 event 的框架,其他像 EAF 一样依赖 Emacs 内部结构的程序必然需要改变。(和 EAF 在 pgtk 下需要改变同样的原因)

编译后也可以在环境中添加 `GDK_CORE_DEVICE_EVENTS=1’ 来关闭 XInput 2。

最好不要把 --with-xinput2 想成 X 上的附加品,而想成其他的窗口系统。

鉴于后续讨论内容已与原主题偏离,特此分割至新主题

8 个赞

代码不会改变的原因是没有可用的改变方式:如果你用 XReparentWindow 把窗口贴到启用 XI2 的 Firefox 上,也会出现类似的问题。如果不使用触摸屏应该不会出现问题。

顺便说一下,我原本发 PSA 的原因就是想收到反馈,问问用户有没有出现问题,结果收到“能否别给开发者创造一些障碍”这样的回答。

触摸屏问题,本来希望会有人用 master 测试 EAF 有否受到影响,如果受到了影响我尽量解决,而动态改变 window-id 纯粹是为了讨论才提到的。

oldosfan的本意是xinput2这个编译选项加了以后EAF就没法稳定获取window-id了。

但是去掉xinput2编译选项后,EAF依然可以正常工作,虽然emacser会面临EAF和xinput2二选一的问题。

开源社区本身就是一种发展过程,只要始终有选择就是好的事情,我相信oldosfan有一天会找到解决xinput2现有bug,同时又不workaround的完美解决方法的,一切交给时间吧。

我前面认为emacs29彻底无法稳定获取window-id导致EAF无法使用,后面oldosfan也清晰的说明只是影响xinput2分支。

既然讨论清楚就行了,如果因为误解导致不合适的过程和行为,我向oldosfan道歉。

看官们就当上面是一种激烈的社区讨论方式吧。

1 个赞

或许是因为我中文不好,但我真没看到,所以才打了这么多字。你要不像我刚才那样,以Q&A的方式把懒猫的Q和你的A一行一行,字字句句quote出来?

早说嘛,这才是我能看到的第一个正面回答 :exploding_head:

目前EAF“必然”需要改变的前提是你apply完你propose的这个workaround破坏掉原本一切正常的window-id吧?至少到目前为止你没说过还有其他哪些问题呀。

对呀,所以按理来说别人提出意见,你好好回答就行了,你是大神,懒猫也是大神,都是这方面的专家,发现proposal出现了不理想的sideaffect,一起坐下来好好讨论如何找到真正双赢的解决方案,不要“我就不改代码,没时间修,你不想用就不用”,这样productive吗?我都有点看不下去了,才掺和进来催你正面答复。

Don’t get so defensive, always assume good intentions.

懒猫这话确实有点激动了。

2 个赞

做为EAF作者最开始认为emacs 29无法再使用EAF了,内心没控制住,我为这句话背后的不当情绪向 @oldosfan 道歉。

以后大家一起好好沟通。

10 个赞

好消息,全屏死机这个问题只有 GNOME 41.1 才会出现,更新到 41.2 后就消失了,所以只需要加到 etc/PROBLEMS 中

6 个赞

看上去挺复杂, emacs有没有可能把后台和显示分开? 类似于neovim? 显示要考虑得东西太多了, 而后台就不一样, 可以很专注. 这样核心开发人员可以专注于后台核心功能

其实 Emacs 已经把后台和显示分开的很不错了,所有的操作都会通过 frame parameter hook、redisplay interface、font driver 和 `struct terminal’ 进行,核心显示代码不需要关注前端细节,只需要使用这些 hook

未来有没有可能让显示和后台跨进程? neovim目前好像是这样, 后台只关注核心功能以及terminal显示, 其他GUI的东西全部不在核心里面, 在外部进程实现. 两者之间有一套RPC协议. 这样核心和GUI的维护完全分离, 而且可以支持第三方的GUI. 核心工作量将会大大减轻.

核心工作量本来就不大,所以没啥必要。反而,跨进程可能产生自由问题。

核心可以优化gc, lisp性能, overlay性能等等, 以及多线程, 充分利用现代cpu多核.

自由问题是不是也可以参考module的设计, 定义一套RPC协议, 协议一开始让客户端先声明自己是GPL的, 否则拒绝连接.

优化 GC、Lisp 和 overlay 性能和维护 gui 代码并不冲突。

不可以,GPL 本质是版权,管不到 RPC。连 RPC 都管就成 EULA 了

进程间通信不是常见的规避GPL的做法吗

显然,Emacs 官方不会鼓励这样的做法

@oldosfan emacs离不开物理键盘啊,建议不要去搞触屏支持