我也正想问这个进展如何了。按原理上不应该慢呀，怎么就失败了呢
時間有點久了, 所以我有點忘了. 主要討論的帖子有點多, 訊息太分散. 不過整理一下, 大概是還在進行中. (抱歉我太快下結論). 我認為不用 libgit2 也是有解決方法的, 不過論哪種方法都需要大量的時間和精力… 言歸正傳, magit/libgit2 最近更新是兩個月前; 
應該還是可以期待下… 吧?
WSL里面emacs有个不好的体验是的全局复制粘贴, 调用的外部命令, 太卡了. 有没有好的方案?
WSL2的粘贴可以直接读Windows的剪切板，复制就需要走其他程序中转一下了。
在WSL2里面运行gui版本的Emacs?
用的xclip+wl-cliploard 还是不错的
2 个赞
这个是可以的，用gtk版本就行，还支持hidpi，只是对多屏切换不友好 ，其他都还不错
新版Emacs 29后，在Windows上已经无法使用Org-mode （v1) 了，一启动就卡住超时。
我这边和之前一样没问题 
magit执行的git命令都是通过调用git cli实现的，换成libgit2需要新增很多函数，magit-libgit中当前只做了magit-bare-repo-p做为示例。
我之前添加过十几个函数，遇到的一点阻碍：
- 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 都可以在新系统下使用。