Re: macosx(carbon): slow keyboard responsiveness bug fix

[CHENG Gao <chenggao@gmail.com>]

*On Mon, 19 Nov 2007 19:38:44 +0900
* Also sprach William Xu <william.xwl@gmail.com>:

> Latest cvs trunk works on macosx again, finally ! 
[...]
> After window-system is changed from frame-local to terminal-local
> variable, since macosx doesn't support MULTI_KBOARD, it looks like the
> window-system misses a chance to be properly set.(leaving it as t by
> default) I doubt other platforms that not yet support MULTI_KBOARD could
> have a similar problem.
>
> Index: src/macterm.c
> ===================================================================
> RCS file: /sources/emacs/emacs/src/macterm.c,v
> retrieving revision 1.238
> diff -u -r1.238 macterm.c
> --- src/macterm.c	1 Nov 2007 03:46:14 -0000	1.238
> +++ src/macterm.c	19 Nov 2007 10:28:13 -0000
> @@ -12772,7 +12772,7 @@
>  mac_create_terminal (struct mac_display_info *dpyinfo)
>  {
>    struct terminal *terminal;
> -  
> +
>    terminal = create_terminal ();
>  
>    terminal->type = output_mac;
> @@ -12838,6 +12838,9 @@
>    if (current_kboard == initial_kboard)
>      current_kboard = terminal->kboard;
>    terminal->kboard->reference_count++;
> +#else
> +  KBOARD *kbp = &the_only_kboard;
> +  kbp->Vwindow_system = intern ("mac");
>  #endif
>  
>    return terminal;

I applied your patch (as mentioned above), and reverted
mac_unicode_keystroke_event in macterm.c to previously correct version,
and edited frame.c as below:
,----
| #ifdef USE_FONT_BACKEND
|   /* Give chance to each font driver to free a frame specific data.  */
|   font_update_drivers (f, Qnil);
| #endif	/* USE_FONT_BACKEND */
`----

then 
./configure --enable-carbon-app
export LIBS=-lresolv (to solve Undefined symbols: _res_init_9)
make bootstrap

I got a successful build of emacs-unicode-2 branch (latest cvs), but
key.mouse respond is still slow and unusable.

But I DO FEEL it's not slow as before. Just still unusably slow.

You said this solved the problem for TRUNK. I just wonder why it does
not work for unicode-2 branch. I read discussions about this problem,
and seems the conclusion is the problem is the same for TRUNK and
unicode-2 branch. (same reason, and I suppose same solution.)


-- 
Ubi bene, ibi patria