Fauli, Can I give you an action item to move emacs now? :) Thanks!
I am not sure if we want bug 268793 to be fixed before. Additionally I don't like the solution to die on USE="X aqua", maybe choosing a default as we do with other Toolkits is best, having aqua as highest in the ordering. Rest of the patch looks ok, although the Prefix ebuild is not fully synced to the tree and needs EAPI 3, not 2. ulm?
(In reply to comment #1) > I am not sure if we want bug 268793 to be fixed before. Definitely. Otherwise I would already have worked on the port, but I see this as a real blocker. > Additionally I don't like the solution to die on USE="X aqua", maybe choosing > a default as we do with other Toolkits is best, Yes. > having aqua as highest in the ordering. On this one I disagree: If we have to choose between a free and a propriatary toolkit, then we should always prefer the free one. We already do it like this for GTK/Xaw3d/MOTIF.
(In reply to comment #2) > (In reply to comment #1) > > I am not sure if we want bug 268793 to be fixed before. > > Definitely. Otherwise I would already have worked on the port, but I see this > as a real blocker. Upstream does not move. Will have no time until Monday to properly write to emacs-devel. Can you? > > having aqua as highest in the ordering. > > On this one I disagree: If we have to choose between a free and a propriatary > toolkit, then we should always prefer the free one. We already do it like this > for GTK/Xaw3d/MOTIF. And I thought because Gtk+ is the prettiest. :) If someone chooses USE=aqua, he likely knows what he is doing (and he only does so on a few profiles), so overriding X is more user-friendly.
(In reply to comment #3) > Upstream does not move. Will have no time until Monday to properly write to > emacs-devel. Can you? It would be best if we had a patch ready for them. Prefix team? > If someone chooses USE=aqua, he likely knows what he is doing (and he only > does so on a few profiles), so overriding X is more user-friendly. But that would imply that we eventually should prefer NeXTStep/GNUstep to GTK+. I'd really like to keep X11/GTK+ as the default. The upstream configure also does this if it detects both. In any case, the ebuild should output a big warning if a user has both X and aqua switched on.
USE=aqua is default on all OSX profiles, so ignoring it and not prefering it over X would really not be what a user would expect. The free toolkit thing doesn't really make sense to me on OSX both aren't in a way. Also, what if gtk+ is compiled with USE=aqua? If emacs compiles with that, you still get a native aqua application, but with non-native elements. Maybe there's just too much choice here.
(In reply to comment #5) > Maybe there's just too much choice here. Please note that we are only discussing the fall-back behaviour in case the user has specified a conflicting combination of flags. It's always possible to say "-aqua X" or "aqua -X". In the "aqua X" case the ebuild shouldn't commit suicide (as the ebuild in the prefix overlay currently does). In addition, I have a slight preference for choosing X, but I could live with the opposite choice too.
(In reply to comment #6) > In the "aqua X" case the ebuild shouldn't commit suicide (as the ebuild in the > prefix overlay currently does). Agreed. I think we all agree with this. > In addition, I have a slight preference for > choosing X, but I could live with the opposite choice too. I would prefer favouring aqua over X, as other ebuilds do as well at the moment.
Taking a detour via the Emacs overlay, as EAPI 4 is not yet allowed in the main tree. Also the ebuild has undergone substantial changes and needs testing. <http://overlays.gentoo.org/proj/emacs/changeset/1561> See also my comment in bug 268793.
A prefix ready emacs-vcs-24.0.9999 is in Emacs overlay too: <http://overlays.gentoo.org/proj/emacs/changeset/1563>
Finally, it's done. :) Thanks to the prefix team for your good work, and for your patience.
migrated, thanks
