emacs-unicode-2 branch - src/macterm.c function mac_set_unicode_keystroke_event - should it be reverted in cvs?

emacs-unicode-2 branch - src/macterm.c function mac_set_unicode_keystroke_event - should it be reverted in cvs?

[CHENG Gao]

In src/macterm.c (emacs-unicode-2 branch), function
mac_set_unicode_keystroke_event is as below:

,----
| static void
| mac_set_unicode_keystroke_event (code, buf)
|      UniChar code;
|      struct input_event *buf;
| {
|   int charset_id, c1, c2;
| 
|   if (code < 0x80)
|     {
|       buf->kind = ASCII_KEYSTROKE_EVENT;
|       buf->code = code;
|     }
|   else if (code < 0x100)
|     {
|       if (code < 0xA0)
| 	charset_id = CHARSET_8_BIT_CONTROL;
|       else
| 	charset_id = charset_latin_iso8859_1;
|       buf->kind = MULTIBYTE_CHAR_KEYSTROKE_EVENT;
|       buf->code = MAKE_CHAR (charset_id, code, 0);
|     }
|   else
|     {
|       if (code < 0x2500)
| 	charset_id = charset_mule_unicode_0100_24ff,
| 	  code -= 0x100;
|       else if (code < 0x33FF)
| 	charset_id = charset_mule_unicode_2500_33ff,
| 	  code -= 0x2500;
|       else if (code >= 0xE000)
| 	charset_id = charset_mule_unicode_e000_ffff,
| 	  code -= 0xE000;
|       c1 = (code / 96) + 32, c2 = (code % 96) + 32;
|       buf->kind = MULTIBYTE_CHAR_KEYSTROKE_EVENT;
|       buf->code = MAKE_CHAR (charset_id, c1, c2);
|     }
| }
`----

From reading this group (gmane.emacs.devel) I got impression that this
function is mis-re-introduced and should be reverted to OLD version as
below:

,----
| static void
| mac_set_unicode_keystroke_event (code, buf)
|      UniChar code;
|      struct input_event *buf;
| {
|   int charset_id, c1, c2;
| 
|   if (code < 0x80)
|     buf->kind = ASCII_KEYSTROKE_EVENT;
|   else
|     buf->kind = MULTIBYTE_CHAR_KEYSTROKE_EVENT;
|   buf->code = code;
| }
`----

Is this correct? If so, could you please revert it in cvs.
Considering the situation that TRUNK is buildable and usable in MacOSX,
and emacs-unicode-2 is buildable (with this revert), it may be
meaningful even though Carbon port is *to some extent* deprecated and
declared unsupported. After all, Cocoa port (http://emacs-app.sf.net) is
not officially planned to merge, and Mac port is only one step away from
working.

-- 
Numquam minus solus quam cum solus

Re: emacs-unicode-2 branch - src/macterm.c function mac_set_unicode_keystroke_event - should it be reverted in cvs?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 22 Nov 2007 00:43:15 +0800, CHENG Gao <chenggao@gmail.com> said:

> Considering the situation that TRUNK is buildable and usable in
> MacOSX,

Not actually for the Carbon port.  Input is only read at the timing of
timer expirations and still less responsive.  You can easily observe
total unresponsiveness by turning off all the timers by invoking Emacs
with -Q -D.

> and emacs-unicode-2 is buildable (with this revert), it may be
> meaningful even though Carbon port is *to some extent* deprecated
> and declared unsupported. After all, Cocoa port
> (http://emacs-app.sf.net) is not officially planned to merge, and
> Mac port is only one step away from working.

Even if you get around the unresponsiveness in the trunk and the
compilation problem in the emacs-unicode-2 branch, the Carbon port
will be unusable anyway when the text drawing in Emacs 23 becomes
font-backend only (unless someone implements font-backend for the
Carbon port).  I don't think it's much meaningful to make the Carbon
port for Emacs 23 work only temporarily.

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

Re: emacs-unicode-2 branch - src/macterm.c function mac_set_unicode_keystroke_event - should it be reverted in cvs?

[William Xu]

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

>  Input is only read at the timing of
> timer expirations and still less responsive.

Why is that? Could you elaborate on that? Is it this the cause of the
responsiveness differences between the TRUNK and 22.1?

-- 
William

http://williamxu.net9.org

Re: emacs-unicode-2 branch - src/macterm.c function mac_set_unicode_keystroke_event - should it be reverted in cvs?

[CHENG Gao]

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

> Even if you get around the unresponsiveness in the trunk and the
> compilation problem in the emacs-unicode-2 branch, the Carbon port
> will be unusable anyway when the text drawing in Emacs 23 becomes
> font-backend only (unless someone implements font-backend for the
> Carbon port). I don't think it's much meaningful to make the Carbon
> port for Emacs 23 work only temporarily.
>
> 				     YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp
I understand this. Maybe it's not meaningful if Cocoa port is planned to
merge.

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

Re: emacs-unicode-2 branch - src/macterm.c function mac_set_unicode_keystroke_event - should it be reverted in cvs?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 22 Nov 2007 12:20:44 +0900, William Xu <william.xwl@gmail.com> said:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> Input is only read at the timing of timer expirations and still
>> less responsive.

> Why is that? Could you elaborate on that? Is it this the cause of
> the responsiveness differences between the TRUNK and 22.1?

As the multi-tty feature is closely related to input handling,
something would have been changed while that feature was being ported
to the Carbon port (not by me).

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

Re: emacs-unicode-2 branch - src/macterm.c function mac_set_unicode_keystroke_event - should it be reverted in cvs?

[Ted Zlatanov]

On Thu, 22 Nov 2007 09:46:21 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 

>>>>>> On Thu, 22 Nov 2007 00:43:15 +0800, CHENG Gao <chenggao@gmail.com> said:
>> Considering the situation that TRUNK is buildable and usable in
>> MacOSX,

YM> Not actually for the Carbon port.  Input is only read at the timing of
YM> timer expirations and still less responsive.  You can easily observe
YM> total unresponsiveness by turning off all the timers by invoking Emacs
YM> with -Q -D.

I observed this over the weekend on Leopard (Mac OS X 10.5.1).  The
Carbon port is usable for short periods, but the constant delay after
each keypress is very annoying.  I would still consider the Carbon port
broken even though it's better than before.  I haven't tested on Tiger
(10.4.x) since I don't have one available.

Ted