Bug 193430 - Fix Emacs and XEmacs support in sci-mathematics/octave
Bug#: 193430 Product:  Gentoo Linux Version: unspecified Platform: All
OS/Version: Linux Status: RESOLVED Severity: normal Priority: P2
Resolution: FIXED Assigned To: metalgod@gentoo.org Reported By: ulm@gentoo.org
Component: Applications
URL: 
Summary: Fix Emacs and XEmacs support in sci-mathematics/octave
Keywords:  
Status Whiteboard: 
Opened: 2007-09-22 15:36 0000
Description:   Opened: 2007-09-22 15:36 0000
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.

------- Comment #1 From Hans de Graaff 2007-09-22 18:41:28 0000 -------
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.

------- Comment #2 From Ulrich Müller 2007-09-22 20:36:01 0000 -------
Thanks Hans.

We also need a new local USE flag:
sci-mathematics/octave:xemacs - Adds support for XEmacs

------- Comment #3 From Ulrich Müller 2007-12-17 11:41:01 0000 -------
No reaction since almost three months.
@sci-mathematics: Is there any reason why this cannot be included?

------- Comment #4 From Markus Dittrich 2007-12-17 14:02:20 0000 -------
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

------- Comment #5 From Ulrich Müller 2007-12-17 14:45:52 0000 -------
(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.

------- Comment #6 From Christian Faulhammer 2007-12-17 15:00:25 0000 -------
(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.

------- Comment #7 From Christian Faulhammer 2007-12-18 07:17:43 0000 -------
Works fine.  Maybe add some additional die statements.

------- Comment #8 From Ulrich Müller 2007-12-18 07:22:38 0000 -------
(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 )

------- Comment #9 From Markus Dittrich 2007-12-18 10:35:28 0000 -------
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

------- Comment #10 From Hans de Graaff 2007-12-24 12:58:52 0000 -------
@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.