> On 2011-09-14 02:43 +0800, John Wiegley wrote:
>> My biggest problem with the Emacs.app code -- and why I'm not using it anymore
>> -- is that subprocess communication is horribly laggy. It makes several Emacs
>> services, such as flyspell, simply unusable. "Mac port" Emacs doesn't have
>> this problem at all, such that flyspell works with the same speed it does on
>> People have commented about this flyspell issue many times, and from what I've
>> seen the blame keeps getting directed at aspell. But actually, it's Emacs.app
>> that is the problem. I've seen it with other things too, like Tramp and gdb,
>> though it's quite as pronounced there since users already expect to wait
> I agree completely. People who have used macport would never want to go
> back to nsport. The difference is that noticeable. We have been hoping
> the nsport get better. It seems 3 years have passed.
Interesting; this is not my experience.
Since switching to macosx I've used both Aquamacs and the mac port, and have always switched back to stock gnu emacs, because what little bit of help I can add seemed best directed there. Most of my time for the last ~10 years has been spent writing english text, rather than coding, so my use of emacs features is pretty spare (text-mode, html-mode; as of ~3 years ago, org-mode). I basically never use tramp, gud/gdb, SLIME, or the like anymore.
I just checked flyspell in one of my recent (org-mode) projects, and it seems more or less instantaneous. I also don't see emacs crashes, although I don't let emacs run for weeks like I used to. I run straight from bzr, rebuilding head every few days.
I'll see if I can make some time this weekend to chase down the common reports, but if a kind someone could let me know what general things seem to be tickling the emacs bugs, I might be able to help out.