Emacs on Aqua (non-religious please)

[bk_usenet@yahoo.co.uk (BK)]

Sorry, but I will respond in respect of what looks likely to lead to
answers to the questions I had asked. Your understanding is
appreciated.

Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de> wrote ...

> > I did read all the docs I could get hold off, but they are written
> > for Gnu Emacs
> 
> Carbon Emacs *is* GNU Emacs.  If there is something in the docs that
> doesn't work as stated, either it's still a todo, or it's a bug in the
> program or the docs.

For the purpose of the questions I had asked Carbon emacs has to be
treated as a separate entity. The commandline version is pre-installed
on OSX at /usr/bin/emacs and it exhibits different behaviour.

Then again, in respect of the following questions the commandline
version is certainly to be considered a different animal ...

1) is file drag and drop intended to work in Carbon Emacs?

NB: I don't care either way, I just want to know so I can document it.

2) is text snippet drag and drop intended to work in Carbom Emacs?

NB: I don't care either way, in fact I think it isn't, but I would
like confirmation so I can document it.

3) is quit from the Emacs menu intended to quit Emacs?

NB: I don't care either wat, I just want to know so I can document it.

4) is quit from the dock menu intended to quit Emacs?

NB: I don't care either wat, I just want to know so I can document it.

5) is paste intended to be greyed out even in the event that something
was pasted into the clipboard in another application ?

6) if the answer to #5 is "yes", then how does one paste from one
application into Emacs?

7) if the answer to #5 is "no", then what needs to be done to make it
work?


All of these questions don't make sense in the commandline version of
Emacs, they are specific to the Carbon version. All of these questions
I ask in earnest.


> It seems that there is (or was) a misunderstanding here.  There is no
> official release of Emacs for MacOSX yet.  MacOSX code is currently
> integrated into the official source code, and you can get that code
> from CVS.  At some point in time some people have made binaries
> available that they compiled themself.

That's useful information and it does explain why there seem to be so
many different Carbon versions and also why all of the ones I tried
exhibited shortcomings that I am convinced no Emacs user would
tolerate.

Do you happen to know when this official release can reasonably be
expected? Again, if possible, I would like to document that.


> You have already been given the two URLs:
> 
>   http://members.shaw.ca/akochoi-emacs/

I did not see any binary on that site

>   http://www.cs.man.ac.uk/~franconi/mac-emacs/

This requires 10.2, right now I am constrained to 10.1.5. However,
this one does look rather promising, so when I get to the 10.2 part
I'll give this a try.


> > > > On a Mac you can just drag a file icon with the mouse onto an
> > > > application icon and the application will open the file.
> 
> Actually I just checked (I wasn't at my Mac the last time) and this
> works fine in the current version.

Can you tell me the version number? Do you know if it is intended to
work in 21.1.30 ?

 
> > No. Ctrl-y (or <C-y> in Emacs lingo) doesn't respond and in the menu
> > it is greyed out.
> 
> It's probably grayed out, because there is nothing in Emacs' internal
> kill-ring currently, which is (to Emacs) the primary source of a
> paste.  A reasonable point that, maybe something could be done about
> it.

Well, fine, so what do I do about it then?

I copied something into the clipboard in another application, now I am
back in Emacs and I want to paste what I have just copied into the
clipboard. What do I have to do?

> 
> > There is no compromise it things like paste <C-y> and quit <C-x>
> > <C-c> don't work out of the box.
> 
> I meant compromise about which keys to actually use.  As I already
> said, the feature itself works here.
> 
> > the application provides a menu that says "Quit" then it should quit
> > if your choose "Quit".
> 
> I have a menu item in my Emacs at the standard Emacs location that
> says "Exit Emacs (C-x C-k)" and it quits the application.  I also have
> the Apple-HIG-demanded "Quit Emacs" in another menu that is grayed
> out, probably because nobody needed it yet.

Well, at least it seems this provides an answer to the question
whether or not "Quit" in the Emacs menu is supposed to quit Emacs.
Although it is odd that yours is greyed out and mine isn't. Anyway, it
seems it is not intended to be  used for quitting, so all I need to do
is find a fix for C-x C-c. Any ideas?

I presume that quitting from the dock is then also not intended to be
available, or what's your take on this?


> > If the implementor doesn't want you to quit from the menu, then why
> > put "Quit" in there in the first place?
> 
> It may have been put there by the OS e.g., trying to enforce HIG.

I think I know enough about OSX application building through using
AppleScript Studio within ProjectBuilder that I can say this is
extremely unlikely. It is certainly not the case with Cocoa, and I
would be extremely surprised if Carbon did not provide the means to
remove it. But anyway this doesn't lead anywhere.

> > Likewise, if the dock menu says "Quit" then the application must
> > quit when you select "Quit".
> 
> And it does here.

Just a moment please. A few lines above you said it was greyed out,
now you say it works. I am confused now. Or do you have *yet another*
"Quit" option. How many "Quit" options do you have?


> > The least broken build I have is 21.1.30, OSX 10.1.5
> 
> I am not sure 10.1 is still supported by the Emacs code, Apple makes
> it not easy to do that.

Well, my aim is to provide information for both users of 10.1.5 and
10.2, if that is possible. Also, I would like to base this on
pre-built binaries because the target audience of a step-by-step
how-to will probably be newbies and I know that many Mac users shy
away from building. In other words I want to make the hurdle as low as
possible so that someone who would like to take a peek at Lisp will be
able to get started without having to make an effort on the editor
side.

On the other hand, if that is too ambitious and it turns out that 10.1
users have to live with various problems if they encounter them, I
guess all I can do is tell them not to expect too much, but if there
is a chance I can avoid that, then I'd like to explore this chance.


> > For most of the keyboard shortcuts it is just deaf, Emacs simply
> > ignores them.
> 
> I assume that C-h l (or M-x view-lossage) doesn't work either.

No M-x works. Luckily. This is how I bring an OpenMCL listener up.
Without that the disaster would be truly complete. ;-)


> did, it would show which events Emacs actually has seen recently.

this is what I get ...

Loads of: <mouse-movement>

followed by: <drag-mouse-1> <down-mouse-1> <mouse-movement> <mouse-1>

and: M-x v i e w - l o s s a g e RET


I presume this tells us nothing, but I hope we can nevertheless take
advantage of the fact that this is working. Can we?

thanks
rgds
bk