I have created a modified version of the emacs-cvs-22.0.50 ebuild that compiles the experimental support for rendering the main text window using Xft. Information about the Xft support can be found at http://www.emacswiki.org/cgi-bin/wiki/XftGnuEmacs I wrote the ebuild as a separate package (emacs-xft), and not a new version of emacs-cvs. In addition to checking out the Xft branch of the Emacs CVS repository, rather than HEAD, it also contains modifications to support the ebuild SLOT being something other than the Emacs version number. (I have this install into the "22.0.50-xft" slot, for instance.) Various parts of the ebuild look for filenames containing the string emacs-${SLOT}; with a non-version slot, emacs-${PV} seemed more appropriate. Reproducible: Always Steps to Reproduce: 1. emerge emacs-xft Actual Results: Xft rendering of main text window in Emacs. Expected Results: N/A
Created attachment 71567 [details] ebuild for emacs-xft-22.0.50
Created attachment 74081 [details, diff] xft-xfaces-fixcrash.patch The first of three patches from this thread: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-07/msg00359.html This particular patch apparently removes a potential crash situation which I was unable to reproduce but it does seem to make sense.
Created attachment 74082 [details, diff] xft-bgalpha.patch This fix is different then whats in the thread I mentioned above but I think it makes more sense as the same variable is not assigned to twice.
Created attachment 74083 [details, diff] xft-invertcursor.patch This patch makes the cursor inverted instead of just a box in the background color. This is especially important if one has blink-cursor-mode disabled.
What are you thoughts on the following idea: Instead of creating a new ebuild, emacs-xft, and instead of copying emacs-cvs, how about we adjust the emacs-cvs-22.0.50.ebuild so that the user can override the ECVS_BRANCH environment variable? ie. Something like what is done in the app-emacs/emms-cvs-0 ebuild: if [ -z "${ECVS_BRANCH}" ]; then ECVS_BRANCH="HEAD" fi Then one could run something like: ECVS_BRANCH=XFT_JHD_BRANCH emerge emacs-cvs The only problem with this is the patches you mention below. They will need to be applied somehow and only when they're not already incorporated into CVS.
I agree about not creating a new ebuild. Can't we do everything based on the xft use flag? I.e., before calling cvs_src_unpack, do something like this: If xft then ewarnbeepmakenoise The XFT branch of emacs is lacking some functionality ewarnbeepmakenoise and sometimes encounters small rendering qlitches. ewarnbeepmakenoise If this sounds scary, consider using -xft ECVS_BRANCH=XFT_JHD_BRANCH else ECVS_BRANCH=HEAD end We can then test the xft use-flag to know whether or not to apply the patches I mentioned above (but see also bug #114501). If, at a later date, those patches get applied upstream, then we could just change the ebuild. Note this would have to be changed because HEAD will not understand --disable-xft: myconf="${myconf} $(use_with xft)" I would submit such an ebuild (I'm currently using my own overlay of emacs-cvs rather than Douglas Creager's emacs-xft) but I don't know how to fix bug #114501.
usata, I CC'd you because you're the most active maintainer of app-editors/emacs-cvs and I'd like to get your input on this. I've attached a proposed patch to our emacs-cvs port. It moves the patching to src_unpack(). I've not tested the ppc port (a PPC patch was moved into src_unpack(), so it needs to be tested). That change should resolve Bug #114501. I've already commited app-editor/emacs-cvs:xft local USE flag to use.local.desc in preparation for the XFT support. Please try this patch out (w/ and w/o XFT support, and on PPC etc.).
Created attachment 74420 [details, diff] emacs-cvs-22.0.50-xft.diff
Using the ebuild emacs-cvs-22.0.50-r1 thats currently in portage with the xft uncommented, I couldn't build emacs with -O3 (resulting error attached). I switched to -O2 and now it compiles (I dimly remember this from last time I played with emacs-xft a few months ago). Anyway, it looks like we may need to filter -O3 at least when xft is enabled (though I haven't tried building it without xft...). i686-pc-linux-gnu-gcc -nostdlib `./prefix-args -Xlinker -z nocombreloc` -Wl,-znocombreloc -o temacs pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o xterm.o xfns.o xselect.o xrdb.o fontset.o xsmfns.o fringe.o image.o gtkutil.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.o terminfo.o lastfile.o vm-limit.o -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpthread -lSM -lICE -ltiff -ljpeg -lpng -lz -lm -lgif -lXpm -lXft -lX11 -lfreetype -lXrender -lfontconfig -lncurses -lm -lgcc -lc -lgcc /usr/lib/crtn.o ./temacs --batch --load loadup bootstrap Loading loadup.el (source)... Using load-path (/var/tmp/portage/emacs-cvs-22.0.50-r1/work/emacs/lisp /var/tmp/portage/emacs-cvs-22.0.50-r1/work/emacs/lisp/emacs-lisp /var/tmp/portage/emacs-cvs-22.0.50-r1/work/emacs/lisp/language /var/tmp/portage/emacs-cvs-22.0.50-r1/work/emacs/lisp/international /var/tmp/portage/emacs-cvs-22.0.50-r1/work/emacs/lisp/textmodes) Loading emacs-lisp/byte-run (source)... Loading emacs-lisp/backquote (source)... Loading subr (source)... Wrong type argument: listp, [] make[2]: *** [bootstrap-emacs] Error 255 make[2]: Leaving directory `/var/tmp/portage/emacs-cvs-22.0.50-r1/work/emacs/src' make[1]: *** [bootstrap-build] Error 2 make[1]: Leaving directory `/var/tmp/portage/emacs-cvs-22.0.50-r1/work/emacs' make: *** [bootstrap] Error 2 !!! ERROR: app-editors/emacs-cvs-22.0.50-r1 failed. Call stack: ebuild.sh, line 1894: Called dyn_compile ebuild.sh, line 941: Called src_compile
=app-editors/emacs-cvs-23* pulls the emacs-unicode-2 branch which includes XFT support (build with USE=xft, and run it with emacs --enable-font-backend --font 'Monospace' to try). Does the emacs-unicode-2 branch include XFT_JHD_BRANCH work>
I think we'll go with emacs-unicode-2 branch in emacs-cvs (23) ebuild and start grooming the emacs-cvs (22) ebuild for the next release.
*** Bug 186843 has been marked as a duplicate of this bug. ***
Reopening for proper closing. emacs-cvs:23 has Xft support since a long time.