luj@Ecn.Purdue.Edu (Jun Lu) (03/08/91)
After I posted my request for the evaluation(Fri, 22 Feb 91 19:58 EST), I've received 7 replies. Thanks to Syd Weinstein(syd@dsinc.dsi.com), David Collier-Brown<davecb@nexus.yorku.ca>, Chris Sherman <sherman@unx.sas.com>, Chris Siebenmann <cks@hawkwind.utcs.toronto.edu>, John R MacMillan <john@scocan.sco.com>, Andrew H. Marrinson<andy@xwkg.icom.com>. Special thanks to John, Andy, and Chris'es for their detailed and solid evaluations. Some people also suggested me to consider mush. But my purpose is not to do an exhaustive survey of the existing mailers; rather I want to compare elm and mh(since they are both accessible to me) so that I can decide which way to go in the long run, based on _my liking_. My apology to all of you if the summary is somehow unintentionally biased. I tried both and I am using both. ELM is very _easy_ to get started. MH seems to more flexible and powerful because its shell environment and message organization allows easy interaction with other unix programs. The big minus side of mh, in my opinion, is the lack of elegant(small and fast) visual front end for reading mh mails(emacs is too hoggy for my 4MB RAM Sun3/60 and going through the learning curves for emacs is no fun. Xmh is also too hoggy. Vmh -- seems not be a good solution either). In case you care, I'm using elm as a front end to read mails in the maildrop and to do simple routine tasks such as reply a mail. But I later inc the mails into MH mailbox to do "post-processing" (pick and refiling ...). My apologies to those respondents if I inadvertently misquoted them. From: John R MacMillan <john@scocan.sco.com> ____________________________________________ | 0. philosophy Elm is designed as a single large program, with full screen interface. When you use elm, you use only elm and little else. There are some basic ways to interact with other unix tools. Like UCB mail, elm stores multiple messages in a single file, making it hard to use unix tools on individual messages. MH is designed as a collection of mail tools, each for performing specific tasks. They are command-line interfaces, and interact easily with other tools. Some basic monolithic (ie. elm-like) front ends are available, like vmh and xmh. Mail messages are stored one per file, making it easy to use other tools. | 2. flexibility( formating the mail ). | interaction with other unix tool No question, MH is more flexible, and interacts better with other tools. | 3. mail filtering( slocal, filter) I've never used the elm filtering, so I can't really say with it. I'm now on an MMDF mail system which uses .maildelivery files like the ones you get from slocal (I believe slocal is largely MMDF source; MH and MMDF are very closely related). They're useful, but not as powerful as I would sometimes like. [My comments(Jun's): MH's slocal is not smart enough to match a regexp. Neither can ELM's filter] | 4. which one are you using ? Why ? I use MH, for a variety of reasons. A major one is the way it interacts with other unix tools, and I'm big on tool use. MH is also better for handling large volumes of mail, and I get quite a bit of mail. MH also has the notion of having a number of draft mail messages that are in progress. I use this idea fairly frequently, and it does not really happen in monolithic mailers. On the down side, there are times when a full screen interface is nice, and MH is lacking in this area. Vmh is not too great, and I'm not big on Xmh either (partially because I'm not big on X). Some MH operations are also slower than they would be in a monolithic mailer, because elm can keep context while it runs, the various MH tools have to store context externally. | 5. other ... I think MH is by far the more powerful, so it comes down to deciding whether a) you need that power, and b) if you want a full screen interface, and Xmh/vmh are good enough. -*-*-*-*- In case those people care and curious, following are more responses. OTHER COMMENTS COLLECTED(Abridged): __________________________________ From: syd@dsinc.dsi.com (Syd Weinstein) ______________________________________ 0. philosophy easy enough for beginners, not too fustrating for experts.(Syd Weinstein) From: Chris Sherman <sherman@unx.sas.com> ________________________________________ Point and click is good for somethings, not for others. I can touch type all the elm commands that I use faster than I can point and click on them. There is no Xelm that I know of. I don't think it needs it. With elm, you will have to learn all the keyboard commands. Give yourself 2 days max before you become an expert. Xmh will take a while too, because I have yet to figure out how to save a piece of mail to a particular name. He's using elm for following reasons: 1) Elm is too much faster than xmh, due to the fact that elm is a text based program instead of graphics based. 2) Elm needs fewer machine resources. I can have elm running all the time without the machine hardly noticing its there. Xmh uses alot of system memory, again because of the graphics. 3) Xmh (at least the version I use on campus) is buggy. Elm is as solid as a rock. From: andy@xwkg.icom.com (Andrew H. Marrinson): ______________________________________________ I use both mh (at work) and Elm (at home). So I can compare the two somewhat for you. > 0. philosophy Mh has a definite philosophy: provide individual programs rather than one big program with many commands. This allows the use of normal Unix tools, and makes mh much more in keeping with the Unix philosophy. One can easily make pipelienes of mh and Unix commands, use mh commands in backquotes, etc. One also finds the writing of aliases (or shell functions) to do particular tasks is quote common. Of course, if one's shell supports it, command history and so on come with this for free. Elm's cheif philosophy seems to be to provide an easy to use (menu-driven) mail system for the user who would be daunted by mailx (aka Mail, aka /usr/ucb/mail) let alone mh. That's not to say it is not useful to more experienced users, but that it is ideal for novice users who don't want to learn much more about Unix than a few simple vi commands and how to run Elm. > 1. easiness to use( Xmh, XElm ?) Elm certainly wins hands-down here. I am the only one at this site (about twenty people) using mh, probably for this very reason. I don't use an X interface, but do use the Emacs (GNU) interface to mh quite extensively. In fact, my chief motivation in switching to mh was that I was unhappy with the rmail package that comes with Emacs, but unwilling to stop using Emacs to read my mail. Anyone can learn Elm quite easily in an evening. There are still whole areas of mh that I don't know, and don't particularly care to delve into. One particularly nice feature of Elm is that all the commands you can use are presented on the screen all the time. This means you hardly have to explain anything to a novice, you just point them at it and away they go. > 2. flexibility( formating the mail ). Mh is by far the winner here. However, mh's formatting capabilities are one of those areas I just haven't been motivated to learn yet. I can say that they look almost painfully complete. Apart from being able to specfify which headers are ignored, I don't think Elm gives you many options here. Then again, I've never needed more than that anyway. As for formatting outgoing mail (not sure what you meant -- formatting mail you were composing, or mail you were reading), Elm and mh both rely on some other editor for the bulk of that work. I use vi with Elm and Emacs with mh. > interaction with other unix tool Again, mh excels at this. Since it is just a collection of Unix programs, you can pipe, etc. to your hearts content. I don't recall Elm providing much in this area, though I haven't really looked. (Hope I'm not misrepresenting the facts.) > 3. mail filtering( slocal, filter) I haven't used this in either Elm or mh. (Though with 50-100 messages a day, I probably should.) I guess I shouldn't comment, therefore. > 4. which one are you using ? Why ? As I said, I use both. Really, I use mh primarily. I started using Elm at home just so I could help other people who were using it. I continue to use it there because mh is a bit of a pain to port and I do prefer Elm to the Emacs rmail package I was using before. (Mainly because it keeps mail in normal mailbox format.) I'll answer this question as though it was mh that I was using, rather than Elm, since that is my primary mail program. I use it first because it has an excellent Emacs package for reading mail in that editor. I like the way it stores folders one file per message (although that can be a pain occassionally). I also like the way it fits in with the Unix philosophy, encouraging the use of pipes, backquotes, and aliases/shell functions to build up commands out of the basic building blocks supplied. Finally, I suppose that, given my love for Emacs, I'm just a sucker for huge bloated software packages :-). > 5. other ... There is one area where I don't like Elm: I often have to edit To: headers to fix up brain-damaged UUCP paths. Elm doesn't make this particularly easy when the path is longer than one line: it doesn't seem to handle backspacing properly in that case. This is a nuisance. When running mh through Emacs at least, the headers are in the editor buffer and I can change them easily using editor commands. Elm puts only the body of your message in the buffer, so you can't use normal editing commands on the headers. (Again, my apologies to Elm fanatics if this has been fixed or I missed something.) To sum up, I guess I'd say go for it with mh. Elm is nice, but mh has all the features anyone could possibly want, and the philosophy of organizing things as seperate Unix commands works great! And if you are an Emacs person (and your mh has been properly configured to work with Emacs) the mh mode of Emacs is the only way to go! An important factor in choosing mh may be the availability of documentation for it. Mh has some excellent documentation, but if you can't get your hands on it, it may be a bit daunting. From: Chris Siebenmann <cks@hawkwind.utcs.toronto.edu> ______________________________________________________ I'm an MH user, what some people might call a power MH user. Here's why I use it and not other things: - it 'thinks' about mail the same way I do; nothing is refiled or deleted or marked unless you explicitly ask for it. (UCB Mail always irritated me with its assumption that once I had even glanced at something that I wanted it deleted or filed away or to have odd headers scribbled over it). - it has very good folder and subfolder and subsubfolder support - it's based around modular programs, each of which does one job; you can string programs together with Unix pipelines and backquoting and shell scripts to make new tools. - it's relatively fast even when handling massive folders (several thousand messages, for example). - there's a good full-screen interface for it in GNU Emacs's mh-e mode. - it's very good about letting you use your programs with it, and not its; editors, pagers, etc. - it has a 'draft folder' feature; you can be writing multiple messages 'simultaneously', or keep around messages that you're working on in a convenient form. - I can hook it into news, so I can write news postings in MH, using the draft folders, the MH 'what now' prompter, and so on; I consider this a heaven-sent improvement over Pnews and friends. -*-*-*-*-*- Have fun, -- Jun -- -- Jun Lu Internet:luj@ecn.purdue.edu -- -- Aeronautics & Astronautics Bitnet: luj%ecn.purdue.edu@purccvm -- -- Purdue University UUCP: pur-ee!luj -- -- W. Lafayette, IN 47907 Phone:317-494-9410 Fax:317-494-0307 --