11:53 p.m.
I’ve synced the carbon2 branch with both the trunk and Andrew Choi’s current
code. There may be some things I’ve missed--that was a lot of syncing--but
the code compiles now and looks and works much as expected. Please test, but
do not distribute binaries.
To get it, do:
cvs -d :pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs login
(it will ask for your password, which is cvs ) followed by
cvs -z3 -d :pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs \
checkout -d xemacs-carbon2 -r carbon2 xemacs
To build, once the checkout is done:
cd xemacs-carbon2/carbon && sh < build-app.sh
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:37 p.m.
Aidan Kehoe wrote:
I’ve synced the carbon2 branch with both the trunk and Andrew Choi’s
current
code. There may be some things I’ve missed--that was a lot of syncing--but
the code compiles now and looks and works much as expected. Please test, but
do not distribute binaries.
To get it, do:
cvs -d :pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs login
(it will ask for your password, which is cvs ) followed by
cvs -z3 -d :pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs \
checkout -d xemacs-carbon2 -r carbon2 xemacs
To build, once the checkout is done:
cd xemacs-carbon2/carbon && sh < build-app.sh
Hi Aidan:
This is great news! But, it looks like you incorporated the
patch event-carbon.c.diff on
http://members.shaw.ca/akochoi-xemacs/Old%20Website/index.html
I don't think this is a good idea. Carbon Emacs and Aquamacs
allow you to use the Option key as Meta. That way you can still
use the Apple key for Mac OS purposes. However, after this patch,
you can't. The Apple key becomes the Meta key and there doesn't
seem to be an easy way to change the code. There was a discussion
of this and a patch way back when, but I can't find either at the
moment. And, IIRC, the original patch gets broken by this latter
patch as well as one that comes even later; maybe
event-carbon2.c.diff?
Rodney
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:09 a.m.
Ar an chéad lá de mí Deireadh Fómhair, scríobh Rodney Sparapani:
But, it looks like you incorporated the patch event-carbon.c.diff on
http://members.shaw.ca/akochoi-xemacs/Old%20Website/index.html
I don't think this is a good idea.
Well you’re talking to the wrong person if you want a patch that adds
comprehensive Unicode input support backed out :-) .
Carbon Emacs and Aquamacs allow you to use the Option key as Meta.
That
way you can still use the Apple key for Mac OS purposes. However, after
this patch, you can't. The Apple key becomes the Meta key and there
doesn't seem to be an easy way to change the code. There was a discussion
of this and a patch way back when, but I can't find either at the moment.
And, IIRC, the original patch gets broken by this latter patch as well as
one that comes even later; maybe event-carbon2.c.diff?
http://groups.google.com/groups?selm=m2wtsw9w1u.fsf＠Owlbear.local describes
his motivations for not adding the mac-command-key-is-meta behaviour. Here’s
the trivial change he mentions; if you apply it locally and set
mac-command-key-is-meta to t, do you get the behaviour you want?
--- event-carbon.c~ 2007-10-02 11:00:35.843750000 +0200
+++ event-carbon.c 2007-10-02 11:06:23.875000000 +0200
＠＠ -37,6 +37,9 ＠＠
extern SELECT_TYPE process_only_mask; /* From event-unixoid.c. */
extern int track_mouse_down_on_scrollbar (void); /* from scrollbar-carbon.c. */
+/* true if using command key as meta key */
+Lisp_Object Vmac_command_key_is_meta;
+
static struct event_stream *carbon_event_stream;
static Lisp_Object carbon_user_event_queue;
＠＠ -250,7 +253,7 ＠＠
{
int emacs_modifiers = 0;
- if (modifiers & cmdKey)
+ if (modifiers & (NILP (Vmac_command_key_is_meta) ? optionKey : cmdKey))
emacs_modifiers |= XEMACS_MOD_META;
if (modifiers & controlKey)
emacs_modifiers |= XEMACS_MOD_CONTROL;
＠＠ -922,6 +925,10 ＠＠
vars_of_event_carbon (void)
{
/* reinit_vars_of_event_carbon (); */
+ DEFVAR_LISP ("mac-command-key-is-meta", &Vmac_command_key_is_meta, /*
+Non-nil means that the command key is used as the XEmacs meta key.
+Otherwise the option key is used. */ );
+ Vmac_command_key_is_meta = Qt;
}
void
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:07 p.m.
Ar an dara lá de mí Deireadh Fómhair, scríobh Aidan Kehoe:
http://groups.google.com/groups?selm=m2wtsw9w1u.fsf＠Owlbear.local
describes
his motivations for not adding the mac-command-key-is-meta behaviour.
And looking at the awkwardness that option-as-meta has provoked with
Aquamacs and layouts where option is used as a dead key, he has a
point--that behaviour really breaks on keyboards where option is needed to
generate a character.
But his code already looks at the currently active layout for keys with the
control modifier; it should be possible to check if option + key is bound in
the OS X keymap when such an event comes in, and to pass the corresponding
character to the event handling code rather than option + key. That seems to
me to be the least surprising behaviour.
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:59 p.m.
Ar an dara lá de mí Deireadh Fómhair, scríobh Aidan Kehoe:
Ar an dara lá de mí Deireadh Fómhair, scríobh Aidan Kehoe:
> http://groups.google.com/groups?selm=m2wtsw9w1u.fsf＠Owlbear.local describes
> his motivations for not adding the mac-command-key-is-meta behaviour.
And looking at the awkwardness that option-as-meta has provoked with
Aquamacs and layouts where option is used as a dead key, he has a
point--that behaviour really breaks on keyboards where option is needed to
generate a character.
But his code already looks at the currently active layout for keys with the
control modifier; it should be possible to check if option + key is bound in
the OS X keymap when such an event comes in, and to pass the corresponding
character to the event handling code rather than option + key. That seems to
me to be the least surprising behaviour.
It’s not practical though, since for most keys option + key generates a
distinct key versus the key on its own in the standard Mac maps. (Things like
œ ˙ é ® þ ¥ for q w e r t z on the German layout.) And there’s no good way
to draw a distinction between option + 4, which generates € and is necessary
for the user, and option + f, which generates ƒ and really isn’t.
The Aquamacs people approach this in a very ad-hoc way, with per-language
tables--see
http://google.com/codesearch?hl=en&lr=&q=file%3Aemulate-mac-keybo...
I suppose though a rule of thumb would be ‘if the character generated with option both:
1. Differs from the character generated without option and
2. Is either ASCII (because our users are programmers) or is necessary to
write the currently active language
then option + char-without-option should generate char-with-option;
otherwise option + char-without-option should generate
M-char-without-option.’ The information on the characters necessary to write
a language is available in the language-specific Quail tables, though it is
incomplete right now.
This is horrible.
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:59 p.m.
Aidan Kehoe wrote:
It’s not practical though, since for most keys option + key generates a
distinct key versus the key on its own in the standard Mac maps. (Things like
œ ˙ é ® þ ¥ for q w e r t z on the German layout.) And there’s no good way
to draw a distinction between option + 4, which generates € and is necessary
for the user, and option + f, which generates ƒ and really isn’t.
The Aquamacs people approach this in a very ad-hoc way, with per-language
tables--see
http://google.com/codesearch?hl=en&lr=&q=file%3Aemulate-mac-keybo...
I suppose though a rule of thumb would be ‘if the character generated with option both:
1. Differs from the character generated without option and
2. Is either ASCII (because our users are programmers) or is necessary to
write the currently active language
then option + char-without-option should generate char-with-option;
otherwise option + char-without-option should generate
M-char-without-option.’ The information on the characters necessary to write
a language is available in the language-specific Quail tables, though it is
incomplete right now.
This is horrible.
I've just starting using Emacs.app for OS X. And, it works the way I
would expect. You can set whichever key that you want to for Meta
(default alt/option) and still use the Apple/Command key (recognized as
super). And, it allows you to do Mule without the problems of Aquamacs.
Instead of Carbon, it uses Cocoa/OpenStep/NextStep/whatever you want
to call it. Maybe this would be a better basis for the XEmacs port to
OS X. I know, patches welcome... But, if anyone is interested, it can
be found at http://emacs-app.sourceforge.net/
Right now, everything seems to work except 2-finger scrolling.
Rodney
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:53 p.m.
Rodney> I've just starting using Emacs.app for OS X.... if anyone is
Rodney> interested, it can be found at http://emacs-app.sourceforge.net/
Yikes! How many different Mac OS X ports of various flavors of Emacs are
available? It seems there are two Carbon-based ports based on the guy
(what's his name? Choi?) who has disappeared (one GNU Emacs, one XEmacs).
There is Aquamacs. There's Emacs.app. Am I missing anything? Why the
explosion in Mac ports?
Skip
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:12 p.m.
skip(a)pobox.com wrote:
Rodney> I've just starting using Emacs.app for OS X....
if anyone is
Rodney> interested, it can be found at http://emacs-app.sourceforge.net/
Yikes! How many different Mac OS X ports of various flavors of Emacs are
available? It seems there are two Carbon-based ports based on the guy
(what's his name? Choi?) who has disappeared (one GNU Emacs, one XEmacs).
There is Aquamacs. There's Emacs.app. Am I missing anything? Why the
explosion in Mac ports?
Skip
Hi Skip:
There is a very brief discussion of that at
http://emacs-app.sourceforge.net/
For example:
On the Mac, this port differs from "Carbon" ports
<http://www.google.com/search?hl=en&lr=&rls=en&q=Carbon+Emacs&...
of GNU Emacs in that it makes a more concerted attempt from the ground
up to follow OS X desktop and UI conventions (without, however, limiting
in any way what you can already do with Emacs). In addition, it runs on
non-Mac platforms via the free GNUstep <http://gnustep.org>
implementation of OS X's Cocoa APIs.
Rodney
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:15 p.m.
Rodney Sparapani wrote:
Hi Skip:
There is a very brief discussion of that at
http://emacs-app.sourceforge.net/
For example:
On the Mac, this port differs from "Carbon" ports
<http://www.google.com/search?hl=en&lr=&rls=en&q=Carbon+Emacs&...
of GNU Emacs in that it makes a more concerted attempt from the ground
up to follow OS X desktop and UI conventions (without, however, limiting
in any way what you can already do with Emacs). In addition, it runs on
non-Mac platforms via the free GNUstep <http://gnustep.org>
implementation of OS X's Cocoa APIs.
Rodney
Oh, I forgot to mention one of the detractions of this API: it is
Objective-C (ObjC) rather than C. Now ObjC is contained in GCC which
makes it more widely available, but it is still something extra to learn :0(
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:03 p.m.
skip(a)pobox.com writes:
Rodney> I've just starting using Emacs.app for OS X.... if anyone is
Rodney> interested, it can be found at http://emacs-app.sourceforge.net/
Yikes! How many different Mac OS X ports of various flavors of Emacs are
available? It seems there are two Carbon-based ports based on the guy
(what's his name? Choi?) who has disappeared (one GNU Emacs, one XEmacs).
Choi is still there, producing occasional improvements to his XEmacs
port. He's a very odd bird, and like Dan Bernstein, insists on
licensing his code in an idiosyncratic and inconvenient way. Unlike
Bernstein, he hasn't a clue about what he is doing, which creates
legal and ethical uncertainty about adopting and distributing his
code.
There is Aquamacs. There's Emacs.app. Am I missing anything?
Why the
explosion in Mac ports?
There are two very different philosophies at work, for one thing.
Aquamacs, in particular, is aiming at an Aqua-conforming editor with
the power of Emacs. The Emacs developers, on the other hand, want
Emacs to run natively on the Mac. I expect Aquamacs to be a fairly
permanent fork.
The Carbon-based ports are very much in line with the "native on Mac"
philosophy. The Cocoa-based ports are necessarily Aqua-conforming,
that's what Cocoa is for. I found the Cocoa-based ports to be
occasionally annoying because of that (don't recall offhand what it
was).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:56 p.m.
Ar an t-aonú lá déag de mí Eanair, scríobh Stephen J. Turnbull:
skip(a)pobox.com writes:
> There is Aquamacs. There's Emacs.app. Am I missing anything? Why the
> explosion in Mac ports?
(Like the explosion in Unix editors way back when; because the program
shipped with the system--in this case, GNU Emacs in a
TTY-only-build--signally failed at exploiting the possibilities of the
platform, and as such couldn’t establish itself as a standard.)
There are two very different philosophies at work, for one thing.
Aquamacs, in particular, is aiming at an Aqua-conforming editor with
the power of Emacs.
If I had had sense three years ago, I would have started a distribution of
XEmacs that did for Win32 what Aquamacs does for OS X, instead of shutting
up after proposing turning on CUA mode by default and getting shot down. The
integration makes the port really much more attractive to users of the
platform. Oh well.
The Emacs developers, on the other hand, want Emacs to run natively
on
the Mac. I expect Aquamacs to be a fairly permanent fork.
The Carbon-based ports are very much in line with the "native on Mac"
philosophy. The Cocoa-based ports are necessarily Aqua-conforming,
that's what Cocoa is for. I found the Cocoa-based ports to be
occasionally annoying because of that (don't recall offhand what it
was).
Did you use Pitts Jarvis’ port at all? Or was that before you moved to OS X?
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:47 p.m.
Ar an deichiú lá de mí Eanair, scríobh Rodney Sparapani:
Aidan Kehoe wrote:
>
> It’s not practical though, since for most keys option + key generates a
> distinct key versus the key on its own in the standard Mac maps.
> (Things like œ ˙ é ® þ ¥ for q w e r t z on the German layout.) And
> there’s no good way to draw a distinction between option + 4, which
> generates € and is necessary for the user, and option + f, which
> generates ƒ and really isn’t.
>
> The Aquamacs people approach this in a very ad-hoc way, with per-language
> tables--see
>
http://google.com/codesearch?hl=en&lr=&q=file%3Aemulate-mac-keybo...
>
> I suppose though a rule of thumb would be ‘if the character generated
> with option both:
>
> 1. Differs from the character generated without option and
> 2. Is either ASCII (because our users are programmers) or is necessary to
> write the currently active language
>
> then option + char-without-option should generate char-with-option;
> otherwise option + char-without-option should generate
> M-char-without-option.’ The information on the characters necessary to
> write a language is available in the language-specific Quail tables,
> though it is incomplete right now.
>
> This is horrible.
I've just starting using Emacs.app for OS X. And, it works the way I
would expect. You can set whichever key that you want to for Meta
(default alt/option) and still use the Apple/Command key (recognized as
super).
And, it allows you to do Mule without the problems of Aquamacs.
How so?
Instead of Carbon, it uses Cocoa/OpenStep/NextStep/whatever you want
to
call it. Maybe this would be a better basis for the XEmacs port to OS X.
I know, patches welcome... But, if anyone is interested, it can be found
at http://emacs-app.sourceforge.net/
Right now, everything seems to work except 2-finger scrolling.
What do you mean by ‘2-finger scrolling?’
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5944
days inactive
6046
days old
11 comments
4 participants
participants (4)
-
Aidan Kehoe -
Rodney Sparapani -
Skip Montanaro -
Stephen J. Turnbull