优化windows版本emacs的总结(持续更新 2024-2-16)

我也正想问这个进展如何了。按原理上不应该慢呀,怎么就失败了呢

時間有點久了, 所以我有點忘了. 主要討論的帖子有點多, 訊息太分散. 不過整理一下, 大概是還在進行中. (抱歉我太快下結論). 我認為不用 libgit2 也是有解決方法的, 不過論哪種方法都需要大量的時間和精力… 言歸正傳, magit/libgit2 最近更新是兩個月前; :thinking: 應該還是可以期待下… 吧?

WSL里面emacs有个不好的体验是的全局复制粘贴, 调用的外部命令, 太卡了. 有没有好的方案?

WSL2的粘贴可以直接读Windows的剪切板,复制就需要走其他程序中转一下了。

在WSL2里面运行gui版本的Emacs?

用的xclip+wl-cliploard 还是不错的

2 个赞

这个是可以的,用gtk版本就行,还支持hidpi,只是对多屏切换不友好 ,其他都还不错

新版Emacs 29后,在Windows上已经无法使用Org-mode (v1) 了,一启动就卡住超时。

我这边和之前一样没问题 :face_with_monocle:

magit执行的git命令都是通过调用git cli实现的,换成libgit2需要新增很多函数,magit-libgit中当前只做了magit-bare-repo-p做为示例。

magit-libgit.el

我之前添加过十几个函数,遇到的一点阻碍:

  • magit-libgit依赖于libegit2,它是基于libgit2 v1版本做的binding,magit对git clit的调用涉及的一些命令行参数不太方便实现。
  • 有些功能在调用libgit2实现后,甚至还没有直接调用命令行花得时间少。

后来有机会用linux办公,就也没折腾了。

我觉得windows下折腾git,也可以想想办法从gitui这个工具入手,看看能不能用emacs给它整个前端

1 个赞

可以用eaf-git跨平台前端

Windows 95, 98 不支持 Unicode API,所以 emacs 不可能完全依赖 W32 的 Unicode API。

这点确实,emacs官方得考虑兼容性。
不过对于我来说兼容性可能就是优化点,我只需要考虑最新win10/11能用,完全可以抛弃某些旧的API或者实现机制

3 个赞

Emacs 在支持 Unicode 的系统下默认使用 wide API,所以没你想象的那种问题。。。

你是指通过宏定义在非老系统启用新api吧。
但是还是在用某些老的机制,比如我最上面提到的那个限制,win上子进程只能有32个,现在通过windows自带的线程池其实是可以解决监听限制64的问题

这个完全不需要宏定义,建议看 w32_unicode_filenames, is_windows_9x, 等。任何新 API 都可以在新系统下使用。