Re: Is Emacs on Aqua crippleware or is it just broken?

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

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

> I understand "crippleware" as an insult without any meaning when
> applied to Emacs, but you hopefully didn't mean it that way.

Crippleware is software that has things left out on purpose which
other versions of the same software have, whether for marketing
reasons or because the developers haven't had the time yet to
implement them doesn't really matter.


> Not to mention that a lot of them
> prefer an Emacs in any usable state instead of not having their
> favorite tool at all (that would be me e.g.).

Same here, but it has got to be in a "usable state". None of the ones
I have tried come even close to being usable.

> OTOH if you really don't like it and don't want or can't spend the
> time to work it out, you are free, go ahead, get something else, there
> are a number of capable editors for MacOSX around, free and
> commercial.

See, I give a damn about that excuse for an editor. All I want to do
is play with Common Lisp, OpenMCL to be precise. Everybody says you
must have Emacs and ILISP to get an IDE for whatever Lisp system you
use. So, I spent already one full week trying to get the recommended
editor working. That's one week wasted which I could have spent doing
CL already. Emacs is a road block. People on the lisp newsgroup have
been very helpful getting ILISP to work and I promised the authors
that I would write a section for their user guide for OSX users who,
like myself will run into the same problem if they want to do Lisp.
You can check out the various mailing lists, they are full with people
who have problems getting past Emacs.

As far as I am concerned, I probably won't touch Emacs with a
barchpole for quite some time. But I have promised to write a section
for the ILISP user guide and I intend to keep that promise. So far
this is incomplete because at the very least, the Common Lisp
HyperSpec must work. So, I will try to find fixes and workarounds so
that I can incorporate them into the documentation. If I can't find
any, well fine, I will just document the shortcomings then.

If you have a Mac, you may want to take a look at Alpaca. This is a
Carbon application, writting in Common Lisp, built with OpenMCL using
Cocoa. It is an Editor like Emacs, it is programmable/configurable in
Common Lisp (not unlike Emacs) and supports drag and drop and
everything else, even Emacs keybindings. Yes, unlike the Emacs builds
I have tried for which the keybindings did not work, they work in
Alpaca. And this has been written by just one guy in his spare time
over the last few months or so. BLESS HIM!!!

http://sourceforge.net/project/showfiles.php?group_id=79717

That's likely what I am going to use.


> I read that as, you are not even sure that you have read and applied
> all the relevant documentation, FAQs etc.  In that case it would be a
> good idea to ask nicely how it's supposed to work, before even using
> the word "bug".

I did read all the docs I could get hold off, but they are written for
Gnu Emacs and/or XEmacs, so there is no way of knowing whether
something has been left out of the Carbon version other than to ask.


> > On a Mac you can just drag a file icon with the mouse onto an
> > application icon and the application will open the file.
> 
> That's not the way Emacs works usually, although it may be a good idea
> to implement it on MacOSX anyway.

Well, I happen to have used some other applications that were
originally X apps and have been ported to the Mac. Typically, the
authors take great pride in making their ports real Mac applications
that take advantage of the Mac environment, ie. such things as drap
and drop.


> Another thought (I haven't tried this).  It may be possible to create
> an emacsclient.command script as a front for emacsclient that you can
> put on your desktop and on which you can drop files.

Sure, but if I'd have to add an extra icon for each application I use
just to bolt on file drag and drop, my dock would get even more
cluttered than it already is.


> > 2) No Drag and Drop - text snippets
> > 
> > On a Mac you can just drag a snippet of text with the mouse from one
> > application and drag it directly into another application.
> 
> You want to implement that?  It is not something that Emacs has on
> other platforms, I think, so it's probably on the very bottom of the
> todo list of anybody else.

Well, Alpaca has this in its 0.4 release. Peanuts.


> As a personal note, I know several Mac users and programmers and most
> of them don't even know that feature, much less use it.  I also know
> no Windows user that knows about that feature, although it does exist
> on Windows with some applications.

I don't really care which one of the copy/paste methods work. However,
I would expect at least one method to work. Because right now I can't
copy and paste between Emacs and other apps at all. That's no good.


> > 3) Systemwide Clipboard - cut and paste
> > 
> > On a Mac you can cut or copy a text snippet to the clipboard while
> > in one application and then paste it back while in another
> > application.
> 
> This works.
> 
> In which way (and for what version of Emacs) doesn't it work for you?

As I said I have tried a handful of Carbon builds and it worked with
none of them.

> You may be confused because Emacs uses different keyboard shortcuts
> for cut-and-paste.

No. Ctrl-y (or <C-y> in Emacs lingo) doesn't respond and in the menu
it is greyed out.

> That's because Emacs defaults were there long
> before MacOS was invented.

Who cares. Give me one method that works and if I can actually
replicate it I will document it. I am not going to document something
i can't replicate and then if people complain, all I have to say is
"someone on usenet said it works this way".


> Some of the keyboard shortcuts can be added as configuration items,
> but some are already taken for other crucial functions in Emacs.  This
> is a problem, and I think the only solution currently is to use some
> compromise.  But there are quite differnt types of users, so I think
> everybody will have to find her/his own compromise on that, that's the
> intention of Emacs' configurability after all.

There is no compromise it things like paste <C-y> and quit <C-x> <C-c>
don't work out of the box.


> > 4) HIG violations - quitting
> 
> You mean MacOSX violating Emacs HIGs?  Emacs is pretty tolerant in
> that area, you know, it accepts whatever the users implement,
> thankfully it doesn't care about the dictates of any company.
> 
> Don't get me wrong, I don't believe that the MacOSX HIGs are bad, they
> are just not gospel to me, so *must* and *can't* are not terms that I
> associate with them.

I am sorry but you are talking complete nonsense here. We are talking
about a way to quit the application. If the application provides a
menu that says "Quit" then it should quit if your choose "Quit". If
the implementor doesn't want you to quit from the menu, then why put
"Quit" in there in the first place?

Likewise, if the dock menu says "Quit" then the application must quit
when you select "Quit". What you are saying is that it would be OK to
write an application for Unix that doesn't respond to HUP or KILL,
simply because the application was ported from some mainframe where
there were no such signals to quit an application.

If it says "Quit" and I select it, then I want it to quit. Anything
else is *BS*.


> If you think so, you should configure your Emacs to do that, where is
> the problem?  Cmd-Q doesn't have any crucial function in Emacs by
> default, I believe, so you are free to do what you want.

Great stuff. You are telling me that it is OK to release an
application that has no other way to be terminated than by using
"force quit" and if I question this, you tell me I should write my own
code to give the application the quit feature that is missing from it.
If you think that this is alright, I can't even begin to imagine what
it takes for you to find something bizarr.

> 
> > 5) HIG violations - paste
> > 
> > On a Mac, cut/copy/paste is Cmd-x/c/v. Emacs doesn't adhere to this,
> > but in principle, this can be changed back to normal by defining
> > keyboard macros.
> 
> See above.

No, not see above. You have ignored the most vital part of my post
which said that whatever I do, paste just doesn't work, not the Mac
way nor the Emacs way, nor any other way.


> > 6) Emacs keyboard shortcuts
> > 
> > Most of the Emacs keyboard shortcuts don't work.
> 
> Not true.

Ah, you are calling me a liar now? Get this: They don't work and there
has just been a posting in comp.sys.mac.apps by a guy who had the same
problem. i have even fired up the old VAX and telneted into the Mac to
see what /usr/bin/emacs does when remotely accessed from there. No
keyboard shortcuts work. The other way (telnet from Mac to VAX, using
Emacs on the VAX) works with /usr/bin/emacs. Of course the Carbon
version cannot be remotely accessed, but it exhibits similar keyboard
shortcut deafness.

> 
> Of course it's possible that something that you want to work one way,
> actually works differently, or even that you really encountered some
> isolated bugs, or something that isn't implemented.

I don't care if it works differently. What I do care is when vital
things such as paste and quit don't work at all, whichever way.


> have to be specific with what you did, what you expected to happen as
> a result, and what happened instead.  And you want to give some data
> on your environment, like your Emacs version, and packages you had
> installed and activated when your did what you did.

The least broken build I have is 21.1.30, OSX 10.1.5 and another Mac
with OSX 10.2.5. Both same behavior.

When I say the keyboard shortcuts don't work at all, I mean exactly
that. For example, normally when you do <C-x> you would get feedback
in the minibuffer at the bottom of the editor window. Well, it doesn't
even do that. For most of the keyboard shortcuts it is just deaf,
Emacs simply ignores them.

And all I loaded at startup was ILISP, which is what many people use,
so there is nothing fishy in there. In fact I got the configuration
file from a guy who is adminstering a few OSX boxes at Berkeley and
all of those machines have the same ILISP setup. They use XEmacs
though.

That's why I ask the questions whether there is anything missing in
the Carbon ports that hasn't been finished yet. It is of no use if I
am trying to fix something that isn't there yet.

> Oh, and it helps
> to be polite and nice, too.

Just because you get offended by the word crippleware doesn't make my
post impolite.


> > 7) User Preferences - Fonts
> > 
> > On just about every Mac application, you can set your preferred font
> > and size. It seems Emacs doesn't allow one to do that. How do you
> > change the font/size?
> 
> You can change the font, but I think this area is work-in-progress

fair enough. this is anyway the least of all worries. Although, some
people may find the font too small to read on higher resolutions.

rgds
bk