all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* macosx(carbon): slow keyboard responsiveness bug fix
@ 2007-11-19 10:38 William Xu
  2007-11-19 15:00 ` Stefan Monnier
  2007-11-20 17:11 ` CHENG Gao
  0 siblings, 2 replies; 15+ messages in thread
From: William Xu @ 2007-11-19 10:38 UTC (permalink / raw)
  To: emacs-devel

Latest cvs trunk works on macosx again, finally ! 

This bug is introduced in: 

,----[ src/macterm.c ]
| Revision 1.237 - (view) (download) (as text) (annotate) - [select for diffs]
| Thu Oct 25 02:38:38 2007 UTC (3 weeks, 4 days ago) by monnier
| Branch: MAIN
| CVS Tags: lexbind-base
| Changes since 1.236: +20 -0 lines
| Diff to previous 1.236
| 
| Make `window-system' into a keyboard-local variable (rather than
| frame-local as done originally by multi-tty).
| 
| * startup.el (window-system): Remove.  Don't make it frame-local.
| 
| * keyboard.h (struct kboard): Add Vwindow_system.
| * keyboard.c (init_kboard): Set a default for Vwindow_system.
| (mark_kboards): Mark Vwindow_system.
| 
| * dispnew.c (syms_of_display) <window-system>: Declare terminal-local.
| (init_display): Don't set the obsolete `window-system' frame-param.
| 
| * xterm.c (x_term_init):
| * w32term.c (w32_create_terminal):
| * term.c (init_tty): Set Vwindow_system.
| * macterm.c (mac_create_terminal): Set a keyboard (missing piece of the
| multi-tty merge maybe?), copied from w32term.c.  Set Vwindow_system.
| 
| * xfns.c (Fx_create_frame, x_create_tip_frame):
| * w32fns.c (Fx_create_frame, x_create_tip_frame):
| * macfns.c (Fx_create_frame):
| Don't set the obsolete `window-system' frame-param.
| 
| * frame.h (Qwindow_system): Remove.
| * frame.c (Qwindow_system): Remove.  In `syms_of_frame' as well.
| (Fmake_terminal_frame): Don't set obsolete `window-system' frame-param.
`----

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;

-- 
William

http://williamxu.net9.org

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: macosx(carbon): slow keyboard responsiveness bug fix
  2007-11-19 10:38 macosx(carbon): slow keyboard responsiveness bug fix William Xu
@ 2007-11-19 15:00 ` Stefan Monnier
  2007-11-20 15:04   ` William Xu
  2007-11-20 17:11 ` CHENG Gao
  1 sibling, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2007-11-19 15:00 UTC (permalink / raw)
  To: William Xu; +Cc: emacs-devel

> 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

Could you try and arange for the Mac OS X to work with MULTI_KBOARD?
It shouldn't be difficult (because even though the generic Emacs code
then supports multiple keyboards, the Mac OS X part of the code can
still choose to only create a single keyboard and work the same as
before).


        Stefan

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: macosx(carbon): slow keyboard responsiveness bug fix
  2007-11-19 15:00 ` Stefan Monnier
@ 2007-11-20 15:04   ` William Xu
  2007-11-20 15:56     ` Andreas Schwab
  2007-11-20 16:53     ` Stefan Monnier
  0 siblings, 2 replies; 15+ messages in thread
From: William Xu @ 2007-11-20 15:04 UTC (permalink / raw)
  To: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Could you try and arange for the Mac OS X to work with MULTI_KBOARD?
> It shouldn't be difficult (because even though the generic Emacs code
> then supports multiple keyboards, the Mac OS X part of the code can
> still choose to only create a single keyboard and work the same as
> before).

Hmm, it turns out easy. Just enable it, then works fairly well. :P 

Well, there's one problem. Some special keys become undefined, like tab,
return, esc. Do you have an idea what might cause this? The following is
a workaround for this: 

,----
| (global-set-key (kbd "<return>") (kbd "RET"))
| (global-set-key (kbd "<tab>") (kbd "TAB"))
`----

The patch: 

Index: darwin.h
===================================================================
RCS file: /sources/emacs/emacs/src/s/darwin.h,v
retrieving revision 1.32
diff -u -r1.32 darwin.h
--- darwin.h	11 Sep 2007 01:04:00 -0000	1.32
+++ darwin.h	20 Nov 2007 14:58:52 -0000
@@ -52,10 +52,6 @@
 #define MAC_OS
 /* We need a little extra space, see ../../lisp/loadup.el. */
 #define SYSTEM_PURESIZE_EXTRA 30000
-
-/* XXX The MULTI_KBOARD support does not work yet on this platform. */
-#undef MULTI_KBOARD
-
 #endif
 #endif

-- 
William

http://williamxu.net9.org

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: macosx(carbon): slow keyboard responsiveness bug fix
  2007-11-20 15:04   ` William Xu
@ 2007-11-20 15:56     ` Andreas Schwab
  2007-11-20 16:53     ` Stefan Monnier
  1 sibling, 0 replies; 15+ messages in thread
From: Andreas Schwab @ 2007-11-20 15:56 UTC (permalink / raw)
  To: William Xu; +Cc: emacs-devel

William Xu <william.xwl@gmail.com> writes:

> Well, there's one problem. Some special keys become undefined, like tab,
> return, esc. Do you have an idea what might cause this? The following is
> a workaround for this: 
>
> ,----
> | (global-set-key (kbd "<return>") (kbd "RET"))
> | (global-set-key (kbd "<tab>") (kbd "TAB"))
> `----

Theses keys should actually be defined in local-function-key-map.
Apparently keyboard specific variables are not yet working correctly.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: macosx(carbon): slow keyboard responsiveness bug fix
  2007-11-20 15:04   ` William Xu
  2007-11-20 15:56     ` Andreas Schwab
@ 2007-11-20 16:53     ` Stefan Monnier
  2007-11-20 17:58       ` Dan Nicolaescu
  1 sibling, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2007-11-20 16:53 UTC (permalink / raw)
  To: William Xu; +Cc: emacs-devel

>> Could you try and arange for the Mac OS X to work with MULTI_KBOARD?
>> It shouldn't be difficult (because even though the generic Emacs code
>> then supports multiple keyboards, the Mac OS X part of the code can
>> still choose to only create a single keyboard and work the same as
>> before).

> Hmm, it turns out easy. Just enable it, then works fairly well. :P 

I didn't dare to suggest that it might work ;-)

> Well, there's one problem. Some special keys become undefined, like tab,
> return, esc. Do you have an idea what might cause this? The following is
> a workaround for this: 

> ,----
> | (global-set-key (kbd "<return>") (kbd "RET"))
> | (global-set-key (kbd "<tab>") (kbd "TAB"))
> `----

These should be set up in function-key-map (or local-function-key-map).
I think the problem might be that mac-win.el sets them up in
local-function-key-map directly from the file's top-level whereas it
should probably do it from the mac-initialize-window-system function.

Take a look at how x-win.el does it: it defines a x-alternatives-map and
then activates it in x-initialize-window-system.  mac-win.el should do
the same (search for "[return]" in both files to see where/how the
binding is created).


        Stefan

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: macosx(carbon): slow keyboard responsiveness bug fix
  2007-11-19 10:38 macosx(carbon): slow keyboard responsiveness bug fix William Xu
  2007-11-19 15:00 ` Stefan Monnier
@ 2007-11-20 17:11 ` CHENG Gao
  2007-11-20 17:52   ` CHENG Gao
                     ` (2 more replies)
  1 sibling, 3 replies; 15+ messages in thread
From: CHENG Gao @ 2007-11-20 17:11 UTC (permalink / raw)
  To: emacs-devel

*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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: macosx(carbon): slow keyboard responsiveness bug fix
  2007-11-20 17:11 ` CHENG Gao
@ 2007-11-20 17:52   ` CHENG Gao
  2007-11-20 23:32   ` Andreas Schwab
  2007-11-21  4:12   ` William Xu
  2 siblings, 0 replies; 15+ messages in thread
From: CHENG Gao @ 2007-11-20 17:52 UTC (permalink / raw)
  To: emacs-devel

A quick followup to this:

I tried again and added 

,----
|   add_keyboard_wait_descriptor (0);
`----

to mac_term_init (macterm.c) right before

,----
| #if USE_CG_DRAWING
|   mac_init_fringe (terminal->rif);
| #endif
`----


then I did "make" instead of "make bootstrap" (since only macterm.c is
changed).

Now emacs runs different from before.

Though I need wait for several seconds to see what I input, I never see
crazy-running busy mouse. I should say it makes me feel better.

Did I add 
,----
| add_keyboard_wait_descriptor (0);
`----
to wrong place? Or should I add something like
,----
| add_keyboard_wait_descriptor (1 or 99999999999 or some-magic-numero-Dieu-sais-seulement);
`----

Any guru can give me a clue? I feel I am just one step away from a
usable emacs-unicode-2 build under MacOSX. TIA!


-- 
Totus mundus agit histrionem

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: macosx(carbon): slow keyboard responsiveness bug fix
  2007-11-20 16:53     ` Stefan Monnier
@ 2007-11-20 17:58       ` Dan Nicolaescu
  2007-11-21  8:59         ` William Xu
  0 siblings, 1 reply; 15+ messages in thread
From: Dan Nicolaescu @ 2007-11-20 17:58 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: William Xu, emacs-devel

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > >> Could you try and arange for the Mac OS X to work with MULTI_KBOARD?
  > >> It shouldn't be difficult (because even though the generic Emacs code
  > >> then supports multiple keyboards, the Mac OS X part of the code can
  > >> still choose to only create a single keyboard and work the same as
  > >> before).

I removed the MULTI_KBOARD define, it was set like that by mistake when
I did the initial multi-tty port to Carbon, and nobody has touched it
much since. Given that now the Carbon port warns that it is non
functional, if anybody wants to get this working, it should be done the
right way.

  > > Hmm, it turns out easy. Just enable it, then works fairly well. :P 
  > 
  > I didn't dare to suggest that it might work ;-)
  > 
  > > Well, there's one problem. Some special keys become undefined, like tab,
  > > return, esc. Do you have an idea what might cause this? The following is
  > > a workaround for this: 
  > 
  > > ,----
  > > | (global-set-key (kbd "<return>") (kbd "RET"))
  > > | (global-set-key (kbd "<tab>") (kbd "TAB"))
  > > `----
  > 
  > These should be set up in function-key-map (or local-function-key-map).
  > I think the problem might be that mac-win.el sets them up in
  > local-function-key-map directly from the file's top-level whereas it
  > should probably do it from the mac-initialize-window-system function.

It's not at the top level, it's in x-setup-function-keys. 
It's confusing because the function is not indented. When I did the
initial multi-tty port I didn't want to make unnecessary changes that
would make merging harder. There's more stuff that needs to be properly
indented in the file, but that would make the unicode-2 merge harder.

  > Take a look at how x-win.el does it: it defines a x-alternatives-map and
  > then activates it in x-initialize-window-system.  mac-win.el should do
  > the same (search for "[return]" in both files to see where/how the
  > binding is created).

I changed it to be similar to what w32-win.el does.

None of these is tested, I don't have access to a mac machine.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: macosx(carbon): slow keyboard responsiveness bug fix
  2007-11-20 17:11 ` CHENG Gao
  2007-11-20 17:52   ` CHENG Gao
@ 2007-11-20 23:32   ` Andreas Schwab
  2007-11-21  0:38     ` YAMAMOTO Mitsuharu
  2007-11-21  2:46     ` CHENG Gao
  2007-11-21  4:12   ` William Xu
  2 siblings, 2 replies; 15+ messages in thread
From: Andreas Schwab @ 2007-11-20 23:32 UTC (permalink / raw)
  To: CHENG Gao; +Cc: emacs-devel

CHENG Gao <chenggao@gmail.com> writes:

> export LIBS=-lresolv (to solve Undefined symbols: _res_init_9)

That should not be necessary any more.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: macosx(carbon): slow keyboard responsiveness bug fix
  2007-11-20 23:32   ` Andreas Schwab
@ 2007-11-21  0:38     ` YAMAMOTO Mitsuharu
  2007-11-21  2:55       ` CHENG Gao
  2007-11-21  4:05       ` William Xu
  2007-11-21  2:46     ` CHENG Gao
  1 sibling, 2 replies; 15+ messages in thread
From: YAMAMOTO Mitsuharu @ 2007-11-21  0:38 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: emacs-devel

>>>>> On Wed, 21 Nov 2007 00:32:20 +0100, Andreas Schwab <schwab@suse.de> said:

> CHENG Gao <chenggao@gmail.com> writes:
>> export LIBS=-lresolv (to solve Undefined symbols: _res_init_9)

> That should not be necessary any more.

But, as I said before, neither calling res_init or linking libresolv
is meaningful/necessary on Mac OS X/Darwin because the actual DNS
resolution is performed outside the Emacs process.

  http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg01254.html

I don't think it is the right thing to add -lresolv without
considering the meaning/necessity of res_init just to superficially
avoid the link error.

Is Mac OS X/Darwin the only such system?  If so, I would rather add
#undef HAVE_RES_INIT and #undef HAVE_LIBRESOLV in src/s/darwin.h.
Otherwise, it might be better to introduce a new macro such as
RESOLVER_EXTERNAL that disables the effect of HAVE_RES_INIT and
HAVE_LIBRESOLV.

				     YAMAMOTO Mitsuhatu
				mituharu@math.s.chiba-u.ac.jp

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: macosx(carbon): slow keyboard responsiveness bug fix
  2007-11-20 23:32   ` Andreas Schwab
  2007-11-21  0:38     ` YAMAMOTO Mitsuharu
@ 2007-11-21  2:46     ` CHENG Gao
  1 sibling, 0 replies; 15+ messages in thread
From: CHENG Gao @ 2007-11-21  2:46 UTC (permalink / raw)
  To: emacs-devel

*On Wed, 21 Nov 2007 00:32:20 +0100
* Also sprach Andreas Schwab <schwab@suse.de>:

> CHENG Gao <chenggao@gmail.com> writes:
>
>> export LIBS=-lresolv (to solve Undefined symbols: _res_init_9)
>
> That should not be necessary any more.
>
> Andreas.
Thanks for your info. I'll try again tonight.

-- 
The truth which makes men free is for the most part the truth which men prefer not to hear.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: macosx(carbon): slow keyboard responsiveness bug fix
  2007-11-21  0:38     ` YAMAMOTO Mitsuharu
@ 2007-11-21  2:55       ` CHENG Gao
  2007-11-21  4:05       ` William Xu
  1 sibling, 0 replies; 15+ messages in thread
From: CHENG Gao @ 2007-11-21  2:55 UTC (permalink / raw)
  To: emacs-devel

*On Wed, 21 Nov 2007 09:38:19 +0900
* Also sprach YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:

> But, as I said before, neither calling res_init or linking libresolv
> is meaningful/necessary on Mac OS X/Darwin because the actual DNS
> resolution is performed outside the Emacs process.
>
>   http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg01254.html
>
> I don't think it is the right thing to add -lresolv without
> considering the meaning/necessity of res_init just to superficially
> avoid the link error.
>
> Is Mac OS X/Darwin the only such system? If so, I would rather add
> #undef HAVE_RES_INIT and #undef HAVE_LIBRESOLV in src/s/darwin.h.
> Otherwise, it might be better to introduce a new macro such as
> RESOLVER_EXTERNAL that disables the effect of HAVE_RES_INIT and
> HAVE_LIBRESOLV.

Thanks for your explanation. I have no idea about dns resolution on
MacOSX. It's just a working workaround I got thru googling. 

-- 
The enemies of Freedom do not argue; they shout and they shoot.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: macosx(carbon): slow keyboard responsiveness bug fix
  2007-11-21  0:38     ` YAMAMOTO Mitsuharu
  2007-11-21  2:55       ` CHENG Gao
@ 2007-11-21  4:05       ` William Xu
  1 sibling, 0 replies; 15+ messages in thread
From: William Xu @ 2007-11-21  4:05 UTC (permalink / raw)
  To: emacs-devel

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> But, as I said before, neither calling res_init or linking libresolv
> is meaningful/necessary on Mac OS X/Darwin because the actual DNS
> resolution is performed outside the Emacs process.
>
>   http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg01254.html

Yes, i can confirm this. I have commented res_init callings, and never
had a DNS resolving problem. 

-- 
William

http://williamxu.net9.org

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: macosx(carbon): slow keyboard responsiveness bug fix
  2007-11-20 17:11 ` CHENG Gao
  2007-11-20 17:52   ` CHENG Gao
  2007-11-20 23:32   ` Andreas Schwab
@ 2007-11-21  4:12   ` William Xu
  2 siblings, 0 replies; 15+ messages in thread
From: William Xu @ 2007-11-21  4:12 UTC (permalink / raw)
  To: emacs-devel

CHENG Gao <chenggao@gmail.com> writes:

> You said this solved the problem for TRUNK. 

Yes. It's definitely usable(I'm using it for daily work), although not
as fast as 22.1(but that's why it is called the 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.)

I have not yet built unicode-2 branch on macosx. So I have no idea of
that at all.

-- 
William

http://williamxu.net9.org

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: macosx(carbon): slow keyboard responsiveness bug fix
  2007-11-20 17:58       ` Dan Nicolaescu
@ 2007-11-21  8:59         ` William Xu
  0 siblings, 0 replies; 15+ messages in thread
From: William Xu @ 2007-11-21  8:59 UTC (permalink / raw)
  To: emacs-devel

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Given that now the Carbon port warns that it is non functional,

It's functional now. Actually ever since i started to build trunk on
macosx in around Sep, it worked fine most of the time, until
20071025. 

> if anybody wants to get this working, it should be done the right way.

No doubt.

> I changed it to be similar to what w32-win.el does.
>
> None of these is tested, I don't have access to a mac machine.

I just managed to bootstrap it. And it did solve the problem. Thanks. :-)

ps. I think the following FIXME could be safely removed now. 

,----[ macterm.c ]
|   /* FIXME: This keyboard setup is 100% untested, just copied from
|      w32_create_terminal in order to set window-system now that it's
|      a keyboard object.  */
`----

pps. Adding the following makes almost no difference here. I'm not sure
whether it's good or bad to add such stuffs. (Give that CHENG Gao was
talking about the unicode-2 branch)

,----
| add_keyboard_wait_descriptor (0);
`----

-- 
William

http://williamxu.net9.org

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2007-11-21  8:59 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-19 10:38 macosx(carbon): slow keyboard responsiveness bug fix William Xu
2007-11-19 15:00 ` Stefan Monnier
2007-11-20 15:04   ` William Xu
2007-11-20 15:56     ` Andreas Schwab
2007-11-20 16:53     ` Stefan Monnier
2007-11-20 17:58       ` Dan Nicolaescu
2007-11-21  8:59         ` William Xu
2007-11-20 17:11 ` CHENG Gao
2007-11-20 17:52   ` CHENG Gao
2007-11-20 23:32   ` Andreas Schwab
2007-11-21  0:38     ` YAMAMOTO Mitsuharu
2007-11-21  2:55       ` CHENG Gao
2007-11-21  4:05       ` William Xu
2007-11-21  2:46     ` CHENG Gao
2007-11-21  4:12   ` William Xu

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.