用SDL3重新实现Emacs 的图形窗口系统

[Kana]

感谢指正！这样看来图形框架的确很能帮助 emacs-reader，我已修正了这部分的评论。

另外，我对 Aleksandr Petrosyan 之前部分博文的意见仍未改变：博文中的对 Emacs 等的贬低，特别是上面“ An Update on the Emacs Widget Project”中的对开发者的诋毁是过分了。这不会为 Emacs 社区或是 Aleksandr Petrosyan 自己的 fork 带来任何好处。若您能与 Aleksandr Petrosyan 友好交流且认同这一点，还希望您能提醒一下 Aleksandr Petrosyan。（因为其文章部分段落看起不像英语母语者写作，因此我希望文章表达出的恶意只是言不达意而已。）

---

Thanks for the correction! It seems that the graphics framework can indeed help emacs-reader a lot. I have corrected this part of the comment.

However, my opinion on some of Aleksandr Petrosyan’s previous posts remains unchanged: the disparagement of Emacs, etc. in the posts, especially the disparagement of developers in “An Update on the Emacs Widget Project” quoted above is excessive. This does not benefit the Emacs community nor their own fork. If you are a friend of Aleksandr Petrosyan and agree with this, I really hope you can remind them of this. (Because parts of the article don’t look like they were written by a native English speaker, I do hope the malicious intent (from my understanding) is more than what was intended.)

[yibie]

Emacs Widget 确实实现得很不完整，本来它应该承担起 Emacs 各种 UI 组件的活儿，但实际上十分有限。

我猜，这也是 @Kinney 放弃原本自己开发的 Emacs Widget Tookit，然后转向开发 ETML 这一套体系的原因。

[SBZORRO]

不太看好， 还不如将elisp发展成独立的语言， 替代guile成为gnu扩展语言来的靠谱。 毕竟elisp是真的有杀手应用。

guile和其他的scheme大都不太健康， 除了chez gambit这种大学教授出来做的， 要不高度特化， 要不半死不活， 要不就是个人项目。 emacs也不是啥简单项目， 竟然还要反馈语言， 是不是过于高估自己的精力了。。。

我认为Alex的方向没问题， 比别的项目靠谱， 最终是要合并回emacs主线的， 唯一的方向。

@yibie

Eventually that code can be subsumed into Emacs, as happend with XEmacs, and it might die a painful slow death as emacs-ng did. This is a me problem now.

最后祝大哥找工作顺利

[a-p-petrosyan]

Hello. I was told I can just post in English, so that’s what I’ll do. I only started studying Mandarin two weeks ago, and don’t trust automatic translators.

The amount of activity here is astonishing. I’m happy that these ideas resonated with this many people.

I’d like to address a few comments.

The Project is Dead.

In some ways it never was alive, because I had a full-time job for the six of the nine months since its “announcement”, and a consulting job until yesterday. I had been working on it in the background, so not much progress. I haven’t lost interest in it. I just have a lot of stuff happening at the same time, so there’s a limited amount of time I can spend on it each day. Sometimes less than an hour. Don’t want people to have the wrong impression.

Disparagement

It was not my intention to be hostile to the mainline community. I had spent a considerable amount of time trying to get a prototype to work, and found that it is mostly difficult because of technical debt. Some of the frustration leaked into the text of the blog posts. I should exercise a bit more control, and be a bit more professional.

That is not to say that I take back any of what is there. I may change the phrasing, but I would convey the message that the code in the upstream Emacs repository is unacceptable. I should perhaps do it in a different way.

Luckily, I want to focus on a prototype that demonstrates the main ideas, without being based on the mainline Emacs.

Prototype

I am at the moment experimenting with low-level Rust graphics bindings.

The reason is threefold.

1. Rust is the language that I am much more productive in. Simply because I’ve been writing Rust full-time for the past five years.

2. Rust removes most of the issues related to build systems, memory leaks (one of which Tushar, Divya and I are struggling with).

3. There’s already a considerable amount of code that is portable. I am working on getting the interpreter in Rune to work with my GUI. I have remacs with many functions already implemented. I have emacs-ng, though I don’t like the direction of the project, it seems that I can borrow code from it.

I will do a prototype in Rust. Iron out the kinks. If the editor is good-enough may be it’d stay a fork.

I’d like upstream Emacs to be able to do the same.

I’m asking people to change the architecture. They are, understandably, not very happy, because I have to “prove” that I know what I’m doing. My work credentials don’t help. I had more than a few conversations (that I can’t post), which come down to “your idea is stupid, don’t waste your time”.

Having a prototype is the only productive way forward. I don’t want to argue, I want to fix problems. And yes, this is doubling the amount of work… but so would be arguments in Emacs-devel. I just choose to spend a bit more time designing something that may itself be useful.

[huangfeiyu]

bro, add oil！

[tusharhero]

@a-p-petrosyan

I will do a prototype in Rust. Iron out the kinks. If the editor is good-enough may be it’d stay a fork.

I’d like upstream Emacs to be able to do the same.

That’s a great idea, I think the article fails to explain this point.

[a-p-petrosyan]

@huangfeiyu Could you paraphrase that? I don’t quite understand what you mean?

[yubaitw]

He meant “加油” in Chinese.

The meaning is close to “You can do it!” or “You got this”.

Note that there’s no corresponding word to “加油” in English.

[zmqclee]

以前看过一部电视剧里面的女主角喊加油的时候会喊“Go!Go!加油”，不知道意思是不是接近一点

[huangfeiyu]

Bro, you have my back!

[huangfeiyu]

你好，把你给刷到了! 正好请教一个问题，怎么设置posframe 中内容和边框的距离呢?eldoc-mouse 使用你的posframe 弹出文档，试了几种方法没能成功。

[tumashu]

据我所知这个好像没什么好方法吧

[huangfeiyu]

但是我看lsp-ui 里面文档和popup 的边框之间是有一定距离的，lsp-ui 应该也是使用的posframe 吧

[tumashu]

看看lsp-ui的代码吧，posframe最开始是用作 pyim 选词框的，后来慢慢变得有点复杂了，现在我自己都感觉控不住了 而且说实话我不喜欢搞涉及窗口之类的代码，感觉特别烦

[huangfeiyu]

要得，我找时间看看lsp-ui 怎么处理的。posframe 用起来非常方便。

[tumashu]

GNU ELPA - buframe 这是今年新出的包，我没测试过，不知道好用不好用

[yibie]

最新关于 SDL 作者的更新：

现在，我们不需要与主线Emacs兼容，图形API的选择要广泛得多。因此，SDL不再是唯一的选择。

我目前正在尝试winit，并正在检查vulkano和wgpu。 vulkano的关键优势是，我可以简单地将着色器暴露在Elisp上，你们就可以把自己打晕了。 缺点是着色器不适合字体渲染。

gpu的关键优势是我们可以将其编译为WASM，并在网络上运行。 这对于像hackmd.io for Org这样的东西特别有用。

[huangfeiyu]

• Non-focusable, non-disruptive, and dedicated to a buffer 它这一点，我就不能用，我需要支持焦点，毕竟文档长了需要滚动查看。

[yibie]

hello，已经 OT 了，关于 posframe 的问题，麻烦转移到对应的帖子下进行讨论，或者另外开启一个帖子。

[a-p-petrosyan]

I see that most activity happens here and only somewhat in the dedicated telegram chats. So I’ll just provide some updates.

I got the text rendering part of the prototype working. I’m now trying to integrate rune, the Rust implementation of the Emacs Lisp interpreter, into an editor that uses Elisp for configuration.

I will then brainstorm ideas about how best to make the architectural changes.

I don’t want this to be a bug-compatible remake of Emacs, just with different underlying technologies. I want something that keeps 90% of what people like about Emacs, and replace the 10% with something else.

For example, I want to introduce the concept of local environments. Such that you have process isolation. This means that if e.g. you need to start an Org buffer, but also computationally heavy task such as bringing up an LSP, you don’t block the same main loop. Elisp is still single-threaded, but these things now happen in separate processes.