我在Windows 上使用Emacs最大的障碍是git太慢了 
1 个赞
这个只能有64子进程（实际是32个）是靠什么解决的？这个问题对于我这种默认开 lsp 的比较难受，过个一两天进程数量就爆了。
根据 w32proc.h 中的说法是因为 Windows 的 WaitForMultipleObjects 这个 api 只支持监控64个子进程，现在包括 zsh 在 Windows 下也像 Emacs 一样只能有 32个子进程。 所以是怎么解决的呢？
要是论坛有个 wiki 页面就好了，这种帖子长了之后每次都要来回翻很久总结
2 个赞
我都习惯了win上magit操作一下喝口水了，急的时候还要换别的工具
1 个赞
你说的对，我上面理解有误，通过WaitForMultipleObjects模拟的情况，只改FD_SETSIZE是没用的。这个问题可能得从模拟机制入手。我前面修改了FD_SETSIZE的值，不会报错，但是应该是没有正常生效
翻了下msdn的文档，应该是可以解决的，它提到了两种解决办法。
一种比较直观的是“创建一个线程来等待 MAXIMUM_WAIT_OBJECTS 句柄，然后等待该线程和其他句柄”
我研究下，链接如下
这个“理论上来说”靠不靠谱？有官方文档或者微软博客上有这么提到过吗？W 的函数性能优于 A 函数？
git还行，慢的是magit，我现在都基本都是vc-dir了，vc功能不够的才用magit
因为nt时代之后，windows内核都是用的UNICODE版本的字符串，就算在用户态用ANSI的API和字符串，传到内核之后还会做转换
我习惯了在win上用magit时操作一下眼睛就离开屏幕休息下。
1 个赞
git for Windows本身就慢，虽然magit也很慢。我现在都直接用WSL了，快到起飞
不能忍, 体验差距太大.
另外, 前几年emacs在mac上magit挺流畅, 跟linux差不多, 后来新版本的macos也不行了(好像是不支持vfork函数了), magit速度跟windows差不多, 让我放弃了mac.
我的情況是, 休息太多次會覺得很煩燥… 
1 个赞
我开始也烦。 Magit在Windows下的体验估计要等到集成了libgit2才会有改善了。
那個不是已經宣告失敗了嗎? 我之前有用過, 但是效能沒有太大提升.
我也正想问这个进展如何了。按原理上不应该慢呀，怎么就失败了呢
時間有點久了, 所以我有點忘了. 主要討論的帖子有點多, 訊息太分散. 不過整理一下, 大概是還在進行中. (抱歉我太快下結論). 我認為不用 libgit2 也是有解決方法的, 不過論哪種方法都需要大量的時間和精力… 言歸正傳, magit/libgit2 最近更新是兩個月前; 應該還是可以期待下… 吧?
WSL里面emacs有个不好的体验是的全局复制粘贴, 调用的外部命令, 太卡了. 有没有好的方案?
WSL2的粘贴可以直接读Windows的剪切板，复制就需要走其他程序中转一下了。
在WSL2里面运行gui版本的Emacs?