

(defun wt/fix-filladapt-fill-paragraph (orig-fun &optional arg) In the meantime, here’s a little piece of function advice that works around the problem temporarily:
#Aquamacs vs emacs mac
The meta-key on the Mac for most flavors of Emacs is the command key, but with Aquamacs it’s the alt/option key. To access ELPA, use the following command: M-x package-list-packages.
#Aquamacs vs emacs install
Therefore, I propose that filladapt be removed from the Aquamacs distribution, or at least not load it by default. The best way to install the necessary packages (clojure-mode, slime, slime-repl, swank-clojure) is by using the Emacs Lisp Package Archive, or ELPA. There’s some disagreement about which one is better, but that is now closer to a matter of taste than basic function. And there are packages out there now using it that way.Īlso, Emacs has also acquired a built-in Adaptive Fill mode. So now if you call (fill-paragraph), it works in standard Emacs, but not in Aquamacs. (fill-paragraph &optional justify region) emacs and relaunch (when (load (expand-file-name '/.emacs.d/package. It also makes it easy to switch between different programs on the Mac.
#Aquamacs vs emacs code
emacs.d directory Add the following code to. Aquamacs is designed to make it easy for users to get started with Emacs. Which was fine then, because it was very useful.īut in 2007, the signature of the standard Emacs fill-paragraph changed from Git clone and copy all the files into the. Among other things, it redefines the standard Emacs fill-paragraph function.Ī long time ago, Aquamacs started including filladapt.el as the default (as far as I can tell, anyway). And running Emacs under X has the disadvantage that Emacs ends up looking quite different typographically than native OS X apps do.Proposal: remove filladapt.el from the Aquamacs distribution:īack in the 90s Kyle Jones wrote filladapt.el for better and more flexible filling of paragraphs, especially in the programming modes. None of the other ports you mention have ever flickered in my experience. To use the option key as your meta key, (setq mac-option-modifier 'meta). So for example if you're on a Macbook, but you are used to the key on the bottom left's being a control key, you would add (setq mac-function-modifier 'control) to your. Just to make sure everyone reading this can follow along: you are probably suggesting using Emacs on the X windowing system on OS X (which would of course require XQuartz to be running).Īnd by "problematic keybindings" you probably mean how most graphical Emacs packages on OS X use the Command modifier key to set the meta bit.īut Mitsuhara Emacs (or emacs-mac as you refer to it) lets you assign any "Emacs modifier bit" (control, meta, alt, hyper or super) to any of OS X's modifier keys (namely, control, option, command or fn) except for the shift key.

If you're using Emacs on OSX, you should be running Yamamoto's port. It has had flicker-free double-buffering for years, smooth (pixel-based) scrolling with inertia, integrated AppleScript bridge, integrated Apple event support, HiDPI, ligatures, graphics/SVG/animations through ImageKit, proper C-g handling, dictionary service support, proper fullscreen, and I could go on and on and on. On the other hand, the Yamamoto Mitsuharu port is rock-solid, functionality is not removed cause Stallman said so, is actively worked on (Yamamoto was the old Carbon Emacs maintainer and knows what he's doing) and uses the latest OSX APIs. It was disappointing to see them following through with these removals. It is heavily modified to look and feel like a native OS X application. It inevitably lags behind GNU Emacs trunk, however. It’s regularly synched with Emacs upstream, though, and closely follows Emacs releases. Unlike all of the above, it’s not based on GNU Emacs, but has an independent source tree. To make matters worse, Stallman has demanded that _useful features be removed_ from the OSX branch, because _Linux doesn't have equivalent APIs_. Aquamacs is a heavily patched fork of GNU Emacs. The end result is that the official OSX Emacs is perpetually buggy (check emacs-devel, it breaks all the time) and lacks a lot of useful features that are available through new OSX APIs.


The OSX support in the mainline Emacs repo (which and aquamacs use) is a third class citizen, since very few people work on it and Stallman is always quick to remind the rest that Linux (sorry GNU/Linux) remains the priority rather than those pesky non-free OSes. This issue is aleady solved in Yamamoto Mitsuharu's Emacs OSX port ( ) which if you use Emacs on OSX is what you should be running (rather than the "official" OSX branch).
