nedit-develop Mailing List for NEdit
Brought to you by:
tringali
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2004 |
Jan
(103) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
(2) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(1) |
2015 |
Jan
|
Feb
|
Mar
(12) |
Apr
(1) |
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ivan S. J. <isj...@i1...> - 2018-05-23 15:36:59
|
Just a (very delayed) update. I had a stab at it a few years ago, but I had to give up. 'int' is used almost everywhere, and when seeing a variable/parameter named "pos" it takes a long time to figure out if it is a byte offset from the start of buffer, window position, a logical cursor position, and absolute column, relative column, etc. Also, in the bowels of the macro language byte offsets are stored as 32-bit integers and it seems a major undertaking in enhancing it to support 64-bit integers. My opinion is that bringing 64-bit file support to nedit is infeasible with the current codebase. /isj |
From: Goetz T. F. <g.f...@r-...> - 2017-01-30 20:04:58
|
despite its many other qualities a major one has always been and still is compatibility. switching to whichever other gui would be a major overhaul and most likely kill that very quality. hence imho something in that regard should not become part of the main branch but either some additional branch or a completely separate project. for such a long standing and mature product like nedit it's very difficult to find actual improvements. i hope not to see the same mistakes here as so many other projects made as in feeling the need to "modernize" some parts just for the heck of it without adding any actual value. but instead ending up with much more limits and obstacles than before. unfortunately the introduction of intptr_t in the current head branch goes in this very direction already. please realize the responsibility you have here, nedit is not only a great editor but also a classy piece of history. On Mon, 30 Jan 2017 11:19:03 -0500, Scott Tringali wrote: > There's a couple of downsides... > > One is conditionalizing it so that it doesn't break for builds that > don't have that version of OpenMotif. Not that I'm a fan, but one very > good thing about nedit is that you can pick it up and build it on a > solaris or irix box without having to go get GTK or build motif yourself > (which might be impossible). > > Porting to GTK would be nice, but then it means it only works on systems > with gtk. If I invested the effort, I'd actually port to something like > wxWidgets. > > _______________________________________________ > nedit-develop mailing list > ned...@li... > https://lists.sourceforge.net/lists/listinfo/nedit-develop -- R-A-C Götz T. Fischer CertIT&Comp +49(0)7225/98 98 79 g.f...@r-... r-a-c.de |
From: Scott T. <sc...@tr...> - 2017-01-30 16:19:21
|
There's a couple of downsides... One is conditionalizing it so that it doesn't break for builds that don't have that version of OpenMotif. Not that I'm a fan, but one very good thing about nedit is that you can pick it up and build it on a solaris or irix box without having to go get GTK or build motif yourself (which might be impossible). Porting to GTK would be nice, but then it means it only works on systems with gtk. If I invested the effort, I'd actually port to something like wxWidgets. On 01/30/2017 07:32 AM, Chris Sorenson wrote: > The latest release of OpenMotif has (supposedly) full > support for UTF8, but coding nedit to make use of it would > be a ton of work. Porting nedit to GTK might make more sense > but would be an even larger task, and, as Mark Edel said in > in his famous nedit slashdot interview 15 years ago, he > didn't think it was worth the effort. That said, the FSF > ported emacs to GTK, so who knows... > |
From: Chris S. <cs...@is...> - 2017-01-30 12:59:08
|
The latest release of OpenMotif has (supposedly) full support for UTF8, but coding nedit to make use of it would be a ton of work. Porting nedit to GTK might make more sense but would be an even larger task, and, as Mark Edel said in in his famous nedit slashdot interview 15 years ago, he didn't think it was worth the effort. That said, the FSF ported emacs to GTK, so who knows... > > Current nedit is just in maintenance mode -- there are no > major features being planned. Unless you're volunteering. > :) > > I imagine utf8 would be a huge overhaul. Most of it's code > was written in the pre-unicode days. > > On 01/27/2017 12:17 PM, ardi wrote: > > What's the current status of Unicode encoding support > > when editing text files with such format in the latest > > releases of NEdit? Years ago Unicode encoding was > > unsupported, but I see some patches published in the > sourceforge page, and I'm also seeing that the recent > > commits seem to suggest a new 5.7 release soon, so I'm > > wondering if it will be possible to work with Unicode > encoding in new versions... > > > I don't know if new Motif versions, like the current > > 2.3.6, might help in this task, BTW. > > > > > ---------------------------------------------------------- > -------------------- Check out the vibrant tech community > on one of the world's most engaging tech sites, > SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > nedit-develop mailing list > ned...@li... > https://lists.sourceforge.net/lists/listinfo/nedit-develop |
From: Scott T. <sc...@tr...> - 2017-01-27 23:15:16
|
Current nedit is just in maintenance mode -- there are no major features being planned. Unless you're volunteering. :) I imagine utf8 would be a huge overhaul. Most of it's code was written in the pre-unicode days. On 01/27/2017 12:17 PM, ardi wrote: > What's the current status of Unicode encoding support when editing > text files with such format in the latest releases of NEdit? Years ago > Unicode encoding was unsupported, but I see some patches published in > the sourceforge page, and I'm also seeing that the recent commits seem > to suggest a new 5.7 release soon, so I'm wondering if it will be > possible to work with Unicode encoding in new versions... > > I don't know if new Motif versions, like the current 2.3.6, might help > in this task, BTW. > |
From: ardi <ard...@gm...> - 2017-01-27 17:18:12
|
What's the current status of Unicode encoding support when editing text files with such format in the latest releases of NEdit? Years ago Unicode encoding was unsupported, but I see some patches published in the sourceforge page, and I'm also seeing that the recent commits seem to suggest a new 5.7 release soon, so I'm wondering if it will be possible to work with Unicode encoding in new versions... I don't know if new Motif versions, like the current 2.3.6, might help in this task, BTW. |
From: Martin A. <ma...@gm...> - 2016-01-27 17:27:58
|
Hi, This is just a test message, please kindly ignore it. Cheers, - Martin - |
From: Goetz T. F. <g.f...@ah...> - 2015-10-14 22:05:41
|
i ran some checks and it turned out that irix defines __unix but not __unix__. at least versions 6.2 and older. i have no 6.3 and 6.4 to check there but since i didn't get that error with 6.5 i guess that one defines __unix__, too. attached is a patch that adds -D__unix__ to the sgi makefile and also fixes 2 non-matching prototypes. by that we have a backward compatibility that goes back more than 20 years. i think that's pretty good :-) "Goetz T. Fischer" wrote: >=20 > the disadvantage with that is that it'd affect all files. i don't know > what > other "results" that might cause. > first thing i'll do is checking the irix headers for __unix__ and see > whether > that's set somewhere. if that's not set at all then using the compiler > option > shouldn't cause trouble. i did however not check yet where and how much > __unix__ is used in the nedit source. by using the compiler option it'd > be set > globally for all files of course. >=20 > On Tue, 30 Jun 2015 15:58:08 -0400, Scott Tringali wrote: > > On 06/30/2015 03:03 PM, Goetz T. Fischer wrote: > > > >> always the native one. i can't stand gcc :-P > > > > It might be easier to use -D__unix__ in the irix makefile. Less likely > > to break... > > > > I think __unix__ is used to distinguish against VMS and OS2 code, so > > IRIX definitely counts. >=20 > -- > ah-consulting.net > G=F6tz T. Fischer CertIT&Comp > Senior Consultant > Phone: +49(0)7225/98 98 79 > eMail: g.f...@ah... > http://www.ah-consulting.net > http://www.ah-webhosting.com >=20 > -------------------------------------------------------------------------= ----- > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > nedit-develop mailing list > ned...@li... > https://lists.sourceforge.net/lists/listinfo/nedit-develop |
From: Goetz T. F. <g.f...@ah...> - 2015-10-14 07:49:37
|
yup On Tue, 13 Oct 2015 21:22:32 -0400, Scott Tringali wrote: > test 2 > > > ------------------------------------------------------------------------------ > _______________________________________________ > nedit-develop mailing list > ned...@li... > https://lists.sourceforge.net/lists/listinfo/nedit-develop |
From: Daniel E. <dei...@fr...> - 2015-10-14 02:04:33
|
On Tue, 13 Oct 2015, Scott Tringali wrote: > Not sure about test 1, but tests 2 and 3 worked. -- DE |
From: Scott T. <sc...@tr...> - 2015-10-14 01:37:59
|
From: Scott T. <sc...@tr...> - 2015-10-14 01:22:40
|
test 2 |
From: Goetz T. F. <g.f...@ah...> - 2015-07-01 02:03:48
|
the disadvantage with that is that it'd affect all files. i don't know what other "results" that might cause. first thing i'll do is checking the irix headers for __unix__ and see whether that's set somewhere. if that's not set at all then using the compiler option shouldn't cause trouble. i did however not check yet where and how much __unix__ is used in the nedit source. by using the compiler option it'd be set globally for all files of course. On Tue, 30 Jun 2015 15:58:08 -0400, Scott Tringali wrote: > On 06/30/2015 03:03 PM, Goetz T. Fischer wrote: > >> always the native one. i can't stand gcc :-P > > It might be easier to use -D__unix__ in the irix makefile. Less likely > to break... > > I think __unix__ is used to distinguish against VMS and OS2 code, so > IRIX definitely counts. -- ah-consulting.net Götz T. Fischer CertIT&Comp Senior Consultant Phone: +49(0)7225/98 98 79 eMail: g.f...@ah... http://www.ah-consulting.net http://www.ah-webhosting.com |
From: Goetz T. F. <g.f...@ah...> - 2015-06-30 18:43:05
|
yeah no problem. there're also 2 non-matching prototypes. sometimes using old compilers reveals more. i'll wrap up a patch covering all the mentioned issues ... On Mon, 29 Jun 2015 22:45:06 -0400, Scott Tringali wrote: > Thanks for the info! It never really went anywhere, just had to clean up > stuff we left hanging. > > I haven't had access to an irix machine in forever. If you can make a patch > I'll surely commit it. I can also make a few stabs if you're willing to > compile and try it, right out of git. > > >> On Jun 29, 2015, at 10:16 PM, Goetz T. Fischer <g.f...@ah...> >> wrote: >> >> hi, >> >> let me say that to me seeing nedit resurrected was one of the nicest >> surprises >> in quite a long time! >> so to contribute at least a little myself i have a quick remark regarding >> irix. >> versions 6.2 and 5.3 in particular. #ifdef __unix__ doesn't work there so >> util/misc.c for example fails because of a missing definition of struct >> timeval >> from sys/time.h. you might wanna add a check for __sgi. >> irix 6.5 doesn't need that but it shouldn't hurt either so checking for __sgi >> should do the trick. >> >> cheers >> >> ------------------------------------------------------------------------------ >> Don't Limit Your Business. Reach for the Cloud. >> GigeNET's Cloud Solutions provide you with the tools and support that >> you need to offload your IT needs and focus on growing your business. >> Configured For All Businesses. Start Your Cloud Today. >> https://www.gigenetcloud.com/ >> _______________________________________________ >> nedit-develop mailing list >> ned...@li... >> https://lists.sourceforge.net/lists/listinfo/nedit-develop -- ah-consulting.net Götz T. Fischer CertIT&Comp Senior Consultant Phone: +49(0)7225/98 98 79 eMail: g.f...@ah... http://www.ah-consulting.net http://www.ah-webhosting.com |
From: Goetz T. F. <g.f...@ah...> - 2015-06-30 02:32:12
|
hi, let me say that to me seeing nedit resurrected was one of the nicest surprises in quite a long time! so to contribute at least a little myself i have a quick remark regarding irix. versions 6.2 and 5.3 in particular. #ifdef __unix__ doesn't work there so util/misc.c for example fails because of a missing definition of struct timeval from sys/time.h. you might wanna add a check for __sgi. irix 6.5 doesn't need that but it shouldn't hurt either so checking for __sgi should do the trick. cheers -- ah-consulting.net Götz T. Fischer CertIT&Comp Senior Consultant Phone: +49(0)7225/98 98 79 eMail: g.f...@ah... http://www.ah-consulting.net http://www.ah-webhosting.com |
From: Ivan S. J. <isj...@i1...> - 2015-04-02 17:56:49
|
On Saturday 28 March 2015 22:15:34 I wrote: > > If someone can help me with the Motif/Lesstif issues that may crop up then I'm willing to give it a shot over the next few weeks. One challenge is that XtMalloc() is extensively used instead of malloc(). XtMalloc/XtRealloc/XtCalloc take the size as a 'Cardinal' which is 32-bit. XtMalloc/XtRealloc/XtCalloc print a warning and exit on out-of-memory. Possibilities: 1: Change to malloc/realloc/calloc/free pro: easy, well-known, better warnings from tools con: on out-of-memory nedit will core/exit 2: Implement nedit_alloc/nedit_realloc/nedit_calloc/... pro: clean exit on out-of-memory con: more work for me. Any strong opinions? /isj |
From: Daniel E. <dei...@fr...> - 2015-03-31 03:25:24
|
On Mon, 30 Mar 2015, Scott Tringali wrote: > Daniel Eischen wrote: > >> The previous releases use to have the man pages generated and included. >> With 5.6, this is no longer the case. There is a stanza in nedit's top >> Makefile that says: >> >> # This should not be in the default build, as users may not have Perl >> # installed. This is only interesting to developers. >> docs: >> (cd doc; $(MAKE) all) >> >> It would be helpful to have the man pages included in the release. >> >> FYI, I am the FreeBSD maintainer for nedit, and will have to deal >> with adding hooks so the man pages can be generated - extra work >> for me since we haven't needed to do so before, and also forces >> perl5 to be installed (the pod2man syntax isn't compatible with >> pod2mdoc as far as I can tell). > > Hi Dan, this was an oversight, as it's been so long since I've made a source > release. I'll regenerate the source package when I get a chance. Thanks! Also, past releases were .bz2, though we can handle .gz just fine. > If possible, can, please link against OpenMotif so there's better font > rendering, not LessTif. By default, we do link with OpenMotif. Only if the build system is overridden does it link with LessTif. I could change FreeBSD's nedit port to forcibly use OpenMotif, but that could possibly cause conflicts with other ports that were specified (overridden) to use LessTif. There can be only one: https://www.youtube.com/watch?v=sqcLjcSloXs Perhaps the proper way to do this would be to mark the port broken (unbuildable/uninstallable) if LessTif were chosen as the system's default Motif, but that seems a tad extreme. I'm not really sure why anyone would want to use LessTif over OpenMotif any more - it's been open-sourced for many years now :-) -- DE |
From: Scott T. <tri...@us...> - 2015-03-31 01:45:53
|
Daniel Eischen wrote: > The previous releases use to have the man pages generated and included. > With 5.6, this is no longer the case. There is a stanza in nedit's top > Makefile that says: > > # This should not be in the default build, as users may not have Perl > # installed. This is only interesting to developers. > docs: > (cd doc; $(MAKE) all) > > It would be helpful to have the man pages included in the release. > > FYI, I am the FreeBSD maintainer for nedit, and will have to deal > with adding hooks so the man pages can be generated - extra work > for me since we haven't needed to do so before, and also forces > perl5 to be installed (the pod2man syntax isn't compatible with > pod2mdoc as far as I can tell). Hi Dan, this was an oversight, as it's been so long since I've made a source release. I'll regenerate the source package when I get a chance. If possible, can, please link against OpenMotif so there's better font rendering, not LessTif. |
From: ardi <ard...@gm...> - 2015-03-30 15:19:38
|
On Sunday, March 29, 2015, Ivan Skytte Jørgensen <isj...@i1...> wrote: > On Sunday 29 March 2015 18:02:37 ardi wrote: > > On Saturday, March 28, 2015, Ivan Skytte Jørgensen <isj...@i1... > <javascript:;>> > > wrote: > > > > > On Friday 27 March 2015 18:00:51 ardi wrote: > > > > If negative, what would be needed to turn NEdit huge-file compatible? > > > > Is it a lot of effort, or can I try it myself? > > > > > > I would say it is a medium-sized task, but will require good tools for > > > finding lossy 64->32 bit conversions. > > > > > > One good approach would be to start changing counters to "size_t", > compile > > in 64bit, and enable compiler warnings to the most pedantic ones. > > The tricky part is to identify which values are sizes and which values are > offsets. > Maybe you can safely make all numbers signed (ptrdiff_t). Yes, size_t can hold a number twice bigger than ptrdiff_t, but at some point the code will need to cast from sizes to offsets and vice versa, so you will never be able to work with a file larger than the largest offset. If you cast to ptrdiff_t everything from the very same moment the file is loaded, maybe it would be safe. > > If NEdit isn't sending the whole text to the widget, I don't think there > > will be any Motif issues when loading >4GB files, as Motif won't be > seeing > > them. > > I'm more concerned about the motif/lesstif/openmotif compatibility issues. > There has been issues with nedit randomly coredumping or not even starting. > My X/Window and Motif knowledge is quite rusty by now. > I've been using NEdit 5.5 on OSX for many years without a crash (compiled as a 64 bit executable). Didn't know there were any problems, although I was using an old OpenMotif 2.3.x version. The only bug I used to hit was the copy/cut/paste key shortcuts stopping to respond, but I thought that was an XQuartz issue. ardi |
From: Daniel E. <dei...@fr...> - 2015-03-30 12:52:41
|
Not sure why this got posted 4 times... On Mon, 30 Mar 2015, Daniel Eischen wrote: > The previous releases use to have the man pages generated and included. > With 5.6, this is no longer the case. There is a stanza in nedit's top > Makefile that says: > > # This should not be in the default build, as users may not have Perl > # installed. This is only interesting to developers. > docs: > (cd doc; $(MAKE) all) > > It would be helpful to have the man pages included in the release. > > FYI, I am the FreeBSD maintainer for nedit, and will have to deal > with adding hooks so the man pages can be generated - extra work > for me since we haven't needed to do so before, and also forces > perl5 to be installed (the pod2man syntax isn't compatible with > pod2mdoc as far as I can tell). > > -- DE |
From: Daniel E. <dei...@fr...> - 2015-03-30 12:47:07
|
The previous releases use to have the man pages generated and included. With 5.6, this is no longer the case. There is a stanza in nedit's top Makefile that says: # This should not be in the default build, as users may not have Perl # installed. This is only interesting to developers. docs: (cd doc; $(MAKE) all) It would be helpful to have the man pages included in the release. FYI, I am the FreeBSD maintainer for nedit, and will have to deal with adding hooks so the man pages can be generated - extra work for me since we haven't needed to do so before, and also forces perl5 to be installed (the pod2man syntax isn't compatible with pod2mdoc as far as I can tell). -- DE |
From: Daniel E. <dei...@fr...> - 2015-03-30 12:47:05
|
The previous releases use to have the man pages generated and included. With 5.6, this is no longer the case. There is a stanza in nedit's top Makefile that says: # This should not be in the default build, as users may not have Perl # installed. This is only interesting to developers. docs: (cd doc; $(MAKE) all) It would be helpful to have the man pages included in the release. FYI, I am the FreeBSD maintainer for nedit, and will have to deal with adding hooks so the man pages can be generated - extra work for me since we haven't needed to do so before, and also forces perl5 to be installed (the pod2man syntax isn't compatible with pod2mdoc as far as I can tell). -- DE |
From: Ivan S. J. <isj...@i1...> - 2015-03-29 16:47:26
|
On Sunday 29 March 2015 18:02:37 ardi wrote: > On Saturday, March 28, 2015, Ivan Skytte Jørgensen <isj...@i1...> > wrote: > > > On Friday 27 March 2015 18:00:51 ardi wrote: > > > If negative, what would be needed to turn NEdit huge-file compatible? > > > Is it a lot of effort, or can I try it myself? > > > > I would say it is a medium-sized task, but will require good tools for > > finding lossy 64->32 bit conversions. > > > One good approach would be to start changing counters to "size_t", compile > in 64bit, and enable compiler warnings to the most pedantic ones. The tricky part is to identify which values are sizes and which values are offsets. > both gcc and clang would do a good task here, showing warnings in all > places where 64bits are being clamped to 32 bits. I have Flexelint, which is better than all the compilers I have encountered. I will use that. > If someone can help me with the Motif/Lesstif issues that may crop up then > > I'm willing to give it a shot over the next few weeks. > > > > If NEdit isn't sending the whole text to the widget, I don't think there > will be any Motif issues when loading >4GB files, as Motif won't be seeing > them. I'm more concerned about the motif/lesstif/openmotif compatibility issues. There has been issues with nedit randomly coredumping or not even starting. My X/Window and Motif knowledge is quite rusty by now. /isj |
From: ardi <ard...@gm...> - 2015-03-29 16:02:44
|
On Saturday, March 28, 2015, Ivan Skytte Jørgensen <isj...@i1...> wrote: > On Friday 27 March 2015 18:00:51 ardi wrote: > > If negative, what would be needed to turn NEdit huge-file compatible? > > Is it a lot of effort, or can I try it myself? > > I would say it is a medium-sized task, but will require good tools for > finding lossy 64->32 bit conversions. One good approach would be to start changing counters to "size_t", compile in 64bit, and enable compiler warnings to the most pedantic ones. I think both gcc and clang would do a good task here, showing warnings in all places where 64bits are being clamped to 32 bits. If someone can help me with the Motif/Lesstif issues that may crop up then > I'm willing to give it a shot over the next few weeks. > If NEdit isn't sending the whole text to the widget, I don't think there will be any Motif issues when loading >4GB files, as Motif won't be seeing them. ardi |
From: Ivan S. J. <isj...@i1...> - 2015-03-28 21:33:20
|
On Friday 27 March 2015 18:00:51 ardi wrote: > Hi, > > I'm subscribing to nedit-develop because I cannot find nedit-discuss > anymore (I suppose that list no longer exists). > > I tried to open a huge file (over 4GB) with a 64bit executable of > NEdit 5.5 some months ago, and it failed. Has this been improved in > 5.6? I did look into it several years ago. I seem to recall that offsets in the the buffer are 32-bit, so you'd probably get into trouble at ~2GB. Hmmm.... Looking at textBuf.h reveals that plain 'int' is used, so nedit woud start failing at files larger than 2^31-1 bytes. > If negative, what would be needed to turn NEdit huge-file compatible? > Is it a lot of effort, or can I try it myself? I would say it is a medium-sized task, but will require good tools for finding lossy 64->32 bit conversions. If someone can help me with the Motif/Lesstif issues that may crop up then I'm willing to give it a shot over the next few weeks. /isj |