[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Carbon port emacs-unicode-2 build problem under MacOSX

From: Ted Zlatanov
Subject: Re: Carbon port emacs-unicode-2 build problem under MacOSX
Date: Tue, 06 Nov 2007 13:26:53 -0600
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1.50 (darwin)

On Tue, 06 Nov 2007 12:34:54 +0000 Jason Rumney <address@hidden> wrote: 

JR> CHENG Gao wrote:
>> Emacs running from terminal works ok. But Emacs.app (running from
>> Finder) is not usable. For every keystroke (keyboard input or mouse
>> click) I have to wait for several minutes. I think it's owing to my
>> brutal revert of mac_set_unicode_keystrok_event which makes
>> do_keystrokes dysfunction.
>> Another possibility is workaround of "export LIBS=-lresolv". I have no
>> idea. Or owing to merge of multi-tty code?
JR> Definitely the merge of multi-tty code, the same problem has been
JR> reported in the trunk multiple times.
JR> macterm.c is missing a call to add_keyboard_wait_descriptor (see xterm.c
JR> and w32term.c), which was necessary to get input working at all on
JR> Windows after the multi-tty merge. Despite this being pointed out
JR> several times, noone who is using a Mac has tried adding this call and
JR> reported back whether it solves the problem.

You must have missed my messages.  I did this several times and reported
that a simple call to add_keyboard_wait_descriptor was not the
solution.  I've tested on Mac OS 10.4 and 10.5.

JR> I think reverting the change is correct, as the old mule based utf
JR> codings are no longer used internally, but it might be a good idea to
JR> find what the change was in the trunk that caused this code to be
JR> merged, as there may be something there that should be changed in the
JR> unicode branch as well.

After trying the Cocoa port, it's actually much better than the Carbon
port, and Carbon is deprecated on MacOS according to Apple (10.5
compilations report deprecated symbols for many Carbon functions).  I
think merging the Cocoa port would be a good thing.  Unfortunately it
doesn't help those who want to track CVS with the Emacs build today, and
I don't know how hard it will be.  Adrian Robert, the maintainer of the
Cocoa port at http://emacs-app.sourceforge.net/, is CCed here in case he
wants to give his opinion.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]