GNU bug report logs - #4322
Carbon Emacs 23.1; first ESC and C-x are always eaten

Previous Next

Full log

Message #37 received at 4322 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
        4322 <at> debbugs.gnu.org,
        Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#4322: Carbon Emacs 23.1; first ESC and C-x are always eaten
Date: Fri, 04 Sep 2009 06:10:44 +0900

>>>>> On Thu, 3 Sep 2009 12:57:43 +0200, Peter Dyballa <Peter_Dyballa <at> Freenet.DE> said:

>> I don't know what "Carbon Emacs 23.1" is.  Is it possibly a new
>> distribution based on Emacs 23 Mac port?

> It's your hack to which I gave this name to make it distinct from
> the X client and the NS variant. I also seem to see some continuity
> and affinity to Carbon Emacsen 22.x. For the future I can omit the
> Carbon categorisation.

One of the reasons I changed the name to the "Mac port" despite the
continuity to some extent is that it is more consistent with other
ports, i.e., it coincides with the `window-system' value (as in W32 or
NS).  Another reason is that it is no longer much meaningful to
mention whether or not it is Carbon/Cocoa: the former is used for
low-level stuff over which Cocoa doesn't provide fine control, and the
latter is used for GUI.  Unlike the Carbon+AppKit port case, there
isn't a counterpart that uses the GUI implementation with Carbon.
Anyway calling it "Carbon Emacs" is inappropriate in any sense.

>> Perhaps next thing you could try is to see if it is also
>> reproducible on the NS port built with a similar "elaborated"
>> configuration, and also try to reproduce it on the Mac port built
>> with a "plain" configuration.  I couldn't reproduce it with the
>> plain one on Mac OS X 10.4 PPC.

> Sorry! I missed to mention that I can't reproduce the effects of C-x
> and ESC in the NS (still here, failing to launch as emacs-23.1-
> mac-1.90/nextstep/Emacs.app/Contents/MacOS/Emacs with options) and
> X11 variants (wrong sequence of compilation, next time it'll be
> hack, NS, X11). These two work well. I could easily persuade them to
> load ucs-normalize, display decomposed characters correctly, and
> also find them in *shell* or dired buffers. BTW, what does "plain"
> mean? Not being allowed to use third party software like that
> distributed by MacPorts or Fink?

I meant so many compiler options and nonstandard load path, but it
would also be meaningful to try to exclude external libraries for
isolating the cause of the problem, as I can't reproduce it here.

Also, it might be the case that the behavior depends on the input
program/mode you are using, or third-party extensions such as SIMBL
plugins if you have installed some.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.