Bugzilla Bug 193430

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 an attachment (id=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.