A mode for octave is included with GNU Emacs since a long time, so for GNU Emacs only the otags binary (and its man page) are needed. XEmacs support could make use of the new xemacs-elisp-common.eclass. Patch will follow.
Created attachment 131630 [details] Patch for octave-2.1.73-r2 The attached patch fixes support for both GNU Emacs and XEmacs. It only installs the otags command for GNU Emacs, and also compiles and installs the elisp files for XEmacs.
Thanks Hans. We also need a new local USE flag: sci-mathematics/octave:xemacs - Adds support for XEmacs
No reaction since almost three months. @sci-mathematics: Is there any reason why this cannot be included?
Hi Ulrich, Sorry for the delay and no excuse, just really busy :( I made myself a note and will try to get it done tonight. That said, we are currently working on the "next generation" octave which is currently being developped in the science overlay (presently we're at octave-2.9.19). Since I am planning on moving octave-2.9.x into the tree sometime in January it would be great if you guys could have a look at its (x)emacs support as well if you get a chance. Thanks in advance, Markus
(In reply to comment #4) > Since I am planning on moving octave-2.9.x into the tree sometime in > January it would be great if you guys could have a look at its > (x)emacs support as well if you get a chance. Looks like the reasoning of comment #0 still applies to octave-2.9.x. Only otags was renamed to octave-tags, otherwise the attached patch (attachment #131630 [details]) should just be applied.
(In reply to comment #5) > (In reply to comment #4) > > Since I am planning on moving octave-2.9.x into the tree sometime in > > January it would be great if you guys could have a look at its > > (x)emacs support as well if you get a chance. > Looks like the reasoning of comment #0 still applies to octave-2.9.x. > Only otags was renamed to octave-tags, otherwise the attached patch > (attachment #131630 [details] [edit]) should just be applied. Yes, it looks as if the spirit of the patch stays the same...will try to emerge octave from the overlay and report back.
Works fine. Maybe add some additional die statements.
(In reply to comment #7) > Maybe add some additional die statements. The xemacs-elisp-* functions die by their own hand, contrary to their elisp-* equivalents. (After all, it's XEmacs, so it has to be incompatible. :-P )
Sorry again for the delay and I've just fixed (x)emacs support in octave-2.1.73-r2. Thanks also for looking into octave-2.9.* and I'll apply the posted patch for 2.1.73-r2 with the naming change mentioned in comment #5. cheers, Markus
@ulm: it seems to make more sense to me for the eclass to handle the die, but I'm happy to change this now that the xemacs eclasses are not heavily used yet. The advantage of die in the eclass is that the ebuild is simpler and the disadvantage is that problems with elisp compilation or installation are always fatal.
