>>>>>> Stefan Monnier <monnier@IRO....> writes:
>> None of that is inherent, i.e. it can all be fixed without having to use a
>> different API. So we need to someone to step up to the plate and provide
> We have an existing body of code that it seems no one is excited to maintain,
> and a fork that at least one person is very eager to maintain.
This viewpoint that does not match the reality I see. Several people
on emacs-devel use the ns port heavily every day, and bugs are both
reported and fixed regularly.
> I then change my font to:
Interesting. I see a problem with this font spec if the emacs window
pre-font-change is tall enough that the post-change window won't fit
on the display. If I use my normal nearly-full-height window with your
font spec, it looks like emacs thinks that window is taller than it
actually is; the scrollbar is the wrong size, the cursor can go above
the window, and there are some display turds that you might expect
from a window that is taller than it thinks it is (most easily seen
with the tool-bar enabled).
If I make the emacs window short enough before changing the font,
everything seems to work fine even with your spec. Hopefully, this
will help someone knowledgeable about the display engine narrow
down the problem area.
> When in a scratch buffer, if I enable flyspell-mode, I can type fast enough
> that Emacs can't insert the characters as quickly as I can type.
I have written a few hundred thousand words of flyspell'd english text
in the ns port, primarily in text-mode and org-mode. Flyspell isn't
fast, due to a known annoyance with the ns port event loop, but it is
certainly not unusable for me (and for many others here), using
relatively modern but not top-of-the-line hardware. I would love to
see if the mac port's approach could improve this; it is far and away
the most exciting potential of the mac port (to me).
Do you still have this problem with flyspell if you run emacs -Q?