MH cleanup and coordination

[Glenn Goldstein]

Hi all:

Jerry> [...] It would be good to get more MH development
Jerry> going... the question is who, and how. A separate
Jerry> nmh-workers group got started last fall, but I think it
Jerry> stalled. Other ideas, folks?

Well, it seems like there are lots of ideas for improvements. Perhaps
it is time to agree upon a collection of changes/improvements and start
implementing them?

I think MH is by far the best mail system and am worried that it is
going to become outdated. I am a programmer but don't have any
knowledge of MH internals. If someone will organize this project I
volunteer to commit some time to help.

I hope we can all contribute a little energy (as a small number are
already contributing a lot) and get something accomplished.

[no...@rand.org]

Glenn Goldstein <go...@elmer.tsc.com> writes:
...

>
>I think MH is by far the best mail system and am worried that it is
>going to become outdated. I am a programmer but don't have any
>knowledge of MH internals. If someone will organize this project I
>volunteer to commit some time to help.
>

me too.

[Stephen Gildea]

> Remove curses internal dependancies from vmh. Also make vmh portable
> between BSD and SYS V curses

A minor point, but as long as you are making lists...

X/Open defines a curses library as part of their Unix specification.
I recommend having vmh use this interface.

< Stephen
X Consortium

[Jerry Peek]

[Sent to: mh-wo...@ics.UCI.EDU, m...@ics.uci.edu, nmh-w...@math.gatech.edu]

Sounds like we've got some momentum going. I just wish we'd hear from
John Romine or anyone else "official" at UCI. It'd really make sense,
IMO, to *coordinate* this with UCI development so that we don't end up
with two or more separate versions of MH. I think that John's
pre-announcement of MH 6.8.4 might have helped to stall the momentum
for the nmh-workers group that started last fall. But now, after the
pre-release, where is 6.8.4? And what next? Hey, UCI: Before a bunch
of us start running off in a different direction from what you might
think is best, can we coordinate? Does UCI want some contributing
MH developers? (Do all you volunteers *want* to coordinate with UCI?)

I vote for waiting a few days -- maybe a week, until 24 March. Between
now and then, keep talking about what needs doing and who might do it.
If we don't get it together with UCI by then, we start working on a new
version. Does that sound reasonable?

I haven't done any group software development, so I probably can't be
too much help. Besides, I've got another time-eating project that I
think I can announce in the next month or two. It should be an
exciting and useful boost to MH documentation. Maybe my project could
be coordinated with the next software release, wherever it comes from.

--Jerry, je...@ora.com

[Richard J. Coleman]

> Sounds like we've got some momentum going. I just wish we'd hear from
> John Romine or anyone else "official" at UCI. It'd really make sense,
> IMO, to *coordinate* this with UCI development so that we don't end up
> with two or more separate versions of MH. I think that John's
> pre-announcement of MH 6.8.4 might have helped to stall the momentum
> for the nmh-workers group that started last fall. But now, after the
> pre-release, where is 6.8.4? And what next? Hey, UCI: Before a bunch
> of us start running off in a different direction from what you might
> think is best, can we coordinate? Does UCI want some contributing
> MH developers? (Do all you volunteers *want* to coordinate with UCI?)

After the announcement that 6.8.4 was coming soon, I put nmh on the
back burner. It's probably a good thing, since I'm cranking back up
my work on zsh.

I still would like to setup a CVS site for mh, give 4 or 5 people access,
and see what happens.

Richard Coleman
col...@math.gatech.edu

[j...@mnsinc.com]

Red Hat has dropped curses from their Linux distribution in favor of
ncurses. Other main-line Linux distributions may follow perhaps
sooner rather than later.

>>>>> "Stephen" == Stephen Gildea "Re: MH cleanup and coordination"
>>>>> 18 Mar 96 17:21:12 GMT

>> Remove curses internal dependancies from vmh. Also make vmh
>> portable between BSD and SYS V curses

Stephen> A minor point, but as long as you are making lists...

Stephen> X/Open defines a curses library as part of their Unix
Stephen> specification. I recommend having vmh use this
Stephen> interface.

jam

[Lance A. Brown]

As far as I know, ncurses is completely function-call compatible with
curses and works as expected in any application where -lcurses,
-ltermcap or -lterminfo is required. I've been able to just replace
them all with -lncurses and compile/run successfully.

MH's habit of munging about in the internals of stdio and curses
really needs to get fixed.

--[lance]

[Steinar Bang]

>>>>> "Lance A. Brown" <lab...@dg-rtp.dg.com>:

> MH's habit of munging about in the internals of stdio and curses
> really needs to get fixed.

Definitely!

What's the reason for this practice? The assumed gain in performance
cannot possibly outweigh the configuration/compilation/etc. etc.
Or...?

[Lance A. Brown]

Steinar Bang <s...@metis.no> writes:

> What's the reason for this practice? The assumed gain in performance
> cannot possibly outweigh the configuration/compilation/etc. etc.
> Or...?

Think about when it was originally done. I expect that was something
like 10 years ago now and machines weren't nearly as speedy or diverse
as they are now.

I'm going to pull out my USENIX proceedings with the sfio stuff in it
and see if that might suite our needs.

--[Lance]