>>>>> On Fri, 7 Dec 2007 00:39:19 -0500, Jason Martens <[EMAIL PROTECTED]> said:
> On Dec 7, 2007, at 12:02 AM, YAMAMOTO Mitsuharu wrote: >> You may also want to look at a related post/thread in >> [EMAIL PROTECTED] about my opinion about the Preferences panel >> Emacs.app provides: >> >> http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg00424.html > Which is all good and well, but you have to admit that a Preferences > panel, no matter how deficient, is a better integration into the Mac > OS X GUI than the Custom buffer. And examples on integration _are_ > what you asked for. That was the context of inclusion of Emacs.app to the core Emacs. Carbon Emacs is already a part of the core Emacs and we shouldn't/can't add a Mac-only Preference panel that is not controllable from Lisp. >> Which version are you using? > The one from here http://homepage.mac.com/zenitani/emacs-e.html. > Emacs 22.1.50.1 It's "Carbon Emacs Package", another distribution based on Carbon Emacs. As it makes some modifications to Carbon Emacs, the problems you experience may or may not be due to such modifications. Anyway, I've never heard of the problems with wheel mouse or process-connection-type you mentioned. >> Modifier mapping is configurable, thanks to David Reitter's work. > They're also modifiable in Emacs.app: what's your point? Maybe I didn't understand what your point was. Didn't you think Emacs.app is better because of its modifier mapping? >>> I can tweak settings with the Property List Editor if I want to. >> >> That's also possible in the Carbon port, in much more compatible >> way with X resources. > Maybe, if you believe that running X for emacs on OS X would provide > that "stable and fully-fledged GNU Emacs functionality" you want. I > personally do not. Moreover, I don't care: I moved to Mac OS X to > get _away_ from X and am much happier as a result. Providing functionality that is compatible with X doesn't mean worse integration with Mac. Also, Emacs has its strength in various third-party elisp packages most of which are made on non-Mac environments. So I think keeping compatibility as much as possible with other platform is important. As for integration with Mac, I would give "graceful termination" as an example. If you try logout/shutdown with leaving file-visiting buffers unsaved, Carbon Emacs pops up a dialog that warns the existence of unsaved buffers. If you cancel the termination of Emacs, the whole logout/shutdown process is canceled immediately. I think such functionality is much much more important for integration with the system rather than key bindings or a Preferences panel. > Look, I'm not trying to step on your toes here; you asked for > "concrete reasons" why one would believe Emacs.app is better than > Carbon. I think I provided you with a few. Take them as you will. > If you don't agree with them then, hey, that's life. I'm just explaining why Carbon Emacs is designed in such a way about what someone think Emacs.app is "much better". YAMAMOTO Mitsuharu [EMAIL PROTECTED] ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Emacs-app-dev- mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emacs-app-dev-
