Apply patch for emacs color disparity

[travis]

Emacs colors don't work as expected, as described here:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8402

Unclear if this is really the one true way to fix this issue, but it seems to work well.

[adamv]

(Some combination of switches to) Emacs doesn't compile against Xcode 4.0. There are some existing issues about this, tagged w/ emacs but I haven't been following them too closely since I don't use Emacs myself.

But I'd love to get it all sorted out, especially w.r.t. HEAD builds and OS X specific patches that people seem to want.

[travis]

Ah ha - @al3x, it looks like you're missing the --HEAD option.

I just installed xcode 4 and was able to reproduce the compilation failure with 23.3. The following installation command worked:

brew install emacs --HEAD --use-git-head --cocoa

The internet seems to think this gist holds the key for compiling emacs 23 with xcode 4:

https://gist.github.com/867129

so I'll try that at some point here.

[travis]

I've tracked down a bit of what's going on here:

Emacs 23.3 as distributed via tarball doesn't compile with xcode 4. I'm not entirely sure why, but the issue appears to be fixed in the emacs-23 branch:

http://git.savannah.gnu.org/gitweb/?p=emacs.git;a=shortlog;h=refs/heads/emacs-23

This means that to install emacs 23 on a system using xcode 4 you need to do something like greymouser and build from the tip of the emacs-23 branch instead of the tarball. This seems like the best option for installing emacs 23 until a new tarball is released, so I've merged emacs-goodness into this pull request for now.

I've tested the result with both master (ie, emacs 24) and emacs-23, and they both seem to work:

brew install emacs --cocoa --HEAD --head-emacs-23

and

brew install emacs --cocoa --HEAD

[adamv]

If other Emacs users think this is the way to go, I can pull this.

[mads-hartmann]

I would very much like to see this get merged.

/Mads

[milkypostman]

I use the patch, but I would strongly vote for making it a configuration option over forcing the patch. I dislike build systems that force patches. I want the ability to build a raw version of a software package.

[travis]

This makes sense to me, especially since I'm still not totally clear if the unpatched behavior is really a bug or just some weirdness I don't understand. I'll try to whip something up tomorrow.

[milkypostman]

I have a commit that incorporates this as an optional build argument, is there a better way to do this?

a748b09551960e8b475c4f8e9e20e73d5411d994

[adamv]

The patch should probably be external, not in __END__; just my 2 cents.

[adamv]

Added this change as a39d6e4

[milkypostman]

this actually seems to be the right way to go about it, but would you still prefer and external patch?

[adamv]

No, I think we're good now. Thanks.