Re: Anybody mind if I remove this piece of strange code?
Neil W Rickert <[EMAIL PROTECTED]> wrote: > Jon Steinhart <[EMAIL PROTECTED]> wrote on Oct 20, 2003: > > > Problem is, > >the folder command doesn't work because there are no subdirectories in the > >mail directory, even though there are links to them. > > It is hard to imagine a Mail directory without at least one > subdirectory (such as RCS). Or +inbox. ;-) -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: Why not document dcc:?
Earl Hood <[EMAIL PROTECTED]> wrote: > Including the additional note about the dangers of using dcc. > Personally, I use dcc when copying myself and bcc when copying > someone else. I personally dislike the bcc behavior of other MUAs > since they provide no indication to the receipient that they have > received a blind-carbon copy. I think the bcc behavior of MH/nmh > is what all MUAs should do. Earl and I are in total agreement here. I can't think of any reasons why we shouldn't document dcc. It works well with building whitelists with procmail, for example. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: default components file
Earl Hood <[EMAIL PROTECTED]> wrote:
> The only potential confusion for new users about "Fcc: +outbox" is
> that when they see it the first time when composing a message, they
> may be confused on exactly what that means.
That's a good point. Here are some other issues that come to mind. In
this discussion, "replcomps" means "replcomps and replgroupcomps".
Note that in replcomps, the Fcc only appears if you specify "repl -fcc
+outbox". But then it does appear in the header.
Whatever we do should be consistent. If we were simply to add "Fcc:
+outbox" to components, we'd make "-fcc +outbox" the default for repl.
This isn't consistent. Fcc would be set in the components file on one
hand, and on the command line in another.
So, one solution would be to add -fcc +outbox to comp and apply
mh-format to components files as well so that Fcc could be controlled by
both the components file and the command line. Perhaps folks would
welcome MH formatting in the components file, but it could be a lot of
work.
Another solution to make things consistent would be to remove the -fcc
option from repl, remove the {fcc} formatting string, and simply add
"Fcc: +outbox" to both components and replcomps. This would be easy, but
would break the ability to set the Fcc depending on whom the message is
addressed. comp is already broken in this regard since it doesn't have a
-fcc option.
Another solution would be to *remove* the Fcc component and {fcc}
formatting string from replcomps and apply Earl's suggestion to both
comp and repl, that -fcc +outbox would be the default for both programs
and operate behind the scenes. This actually has a *lot* of appeal to
me.
Even though Ruud make a good point about the difference between outbox
and sent-items in other mailers, I'm not sure how applicable this
argument is to MH, since the parallel between inbox and outbox is so
strong.
The default for the -fcc option would thus be +outbox, which could be
overridden with a different -fcc option (like sent-items ;-) or turned
off entirely with -nofcc.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.
Re: default components file
Glenn Burkhardt <[EMAIL PROTECTED]> wrote: > I'd like to change the default components file to include a folder copy: > > To: > cc: > Fcc: +sent-mail > Subject: > Obviously it won't be a clear majority, but perhaps there will be some consensus. I think a Fcc out of the box is entirely appropriate for new users. The Dcc usage that Earl suggests is a little more advanced, and is typically used with procmail which is even more advanced (although it is absolutely necessary these days). And remember that Dcc is still undocumented and thus shouldn't be added to the default files. I've been using "Fcc: +out" for years. Inevitably, I get a "I lost your mail, please resend" at least once a month, and I often remind myself what I said. Perhaps Earl hasn't quite hit the magic-40 senility barrier yet ;-). While I use +out, I think +outbox is more MH-like than +sent-mail and would vote for +outbox for the default and may well edit my own components file accordingly now that I'm thinking of it. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: Should nmh be RFC 2822 compliant (bug report #3356)
Glenn Burkhardt <[EMAIL PROTECTED]> wrote: > Should we change [In-Reply-To]? The entire MH-E crew is behind this change (and it was one of us who submitted it ;-). It will make the MH-E threading code more reliable. Note that the new format is backwards-compatible with the old spec so there shouldn't be much harm in implementing it unless there are some MUAs out there that misread the spec and didn't make the phrase optional. But I wouldn't worry about it as these mailers will also have problems with any other RFC 2822-compliant MUA. Thanks tons for digging in and working on nmh! -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: the release (Re: Solaris 'vim' configure bug)
[EMAIL PROTECTED] wrote: > At least one patch (kre's) fixed a security bug (from memory). > It'd be a shame to release without fixing those. Not to mention Mark's patch to fix broken scan lines. Since MH-E is already in an editor, it doesn't *call* an editor; so it is agnostic here. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: Scan of folders with 10k+ messages?
Harlan Stenn <[EMAIL PROTECTED]> wrote: > I have a folder with more than 10k messages in it. > > Scan now displays these messages as ?nnn, where nnn is really digits. > > What do I need to hack to allow for a wider field? Copy /etc/nmh/scan.default into your Mail directory and s/%4(msg)/%5(msg)/. Or use MH-E which does this automatically for you (mh-e.sourceforge.net) ;-). -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: Improving attachment viewing
So to summarize thus far, the MH-E needs of nmh are: - A boolean function for mh-format which is true if attachments are present (say, called "attach"). - Content-Disposition support (inline, attachment, filename). - Better PGP/MIME (RFC 3056) composition (perhaps this *can* be accomplished with the the #begin directive, although it would definitely be tedious to do manually.) S/MIME? -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: Improving attachment viewing
Oliver Kiddle <[EMAIL PROTECTED]> wrote: > What bothers me more about mime handling is the lack of formatting of > messages before quoting the message in a reply. Yes, this was one of the issues we addressed in MH-E. If you have repl incorporate the text parts of the message to which you're replying, it should perform quoted-printable and base64 decoding. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: Improving attachment viewing
Scott Schwartz <[EMAIL PROTECTED]> wrote: > Perhaps "next -part" would be the right user interface (ignoring all > coding considerations) to step thru attachements, leaving "next" for > whole messages. Agreed. > It seems to me that the main difficulty is that mh stores one message > per file, but MIME ruins that model by introducing nesting. Wonder if something like burst that takes message m with attachments and creates files m.n would be useful... -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: nmh 1.1?
[EMAIL PROTECTED] wrote: > It has been fixed. I was just grousing that the fix has been in CVS for > a couple years but not in the Redhat distributions. Rather than grouse, switch to Debian GNU/Linux: nmh 1.0.4+dev-20010317-1 -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Improving attachment viewing
I've changed the Subject and included [EMAIL PROTECTED] since we've spent the last year improving MIME handling in Gnus since raw MH wouldn't work for us. We should be able to provide some suggestions which would allow us to use more MH and less Gnus. Peter? Satyaki? Jon Steinhart <[EMAIL PROTECTED]> wrote: > My interest in m_getfld is because I'd like to experiment with the way > that attachments are shown. It'd be interesting to get a bit of > discussion on this. Basically, I don't like the way that message parts > are treated differently than messages. To me, there's little > difference between receiving a message with two attachments and three > messages. I'd like to see an indented scan that shows something like > > 5785+ 11/19 Eric Gillespie Re: The continuing install-mh saga< .1 > .2 > > ant then be able to do show/next/prev on stuff. I find it really > annoying to have all body parts displayed in a single batch, > especially those that involve some interaction to get rid of, like > closing an image viewer. This might be an intriguing option to some, but it should not be the default. I wouldn't enable it. There is too much crap out there that would pollute the scan listing and make it awkward to read mail quickly. I can safely say that I do not view the majority of attachments I receive and considering them as separate messages would simply add the to (often oppressive) pile of mail. Consider all the midi and html attachments in spam, and winmail.dat attachments, and vCards, and multipart/encrypted which you would want to present as a single message rather than the pieces. To name just a few. You'll be sure to generate some good ideas though. Capture them in a Feature Request at Savannah. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: The continuing install-mh saga
Jon Steinhart <[EMAIL PROTECTED]> wrote: > but should it > really be called install-nmh? No, nmh is pronounced MH. Note that Richard Coleman wisely called the new commands mhbuild, mhstore, and so on, not nmhbuild, nmhstore, etc. nmh is, and should continue to be, backwards-compatible so it won't confuse old users and break old scripts. Another reason to minimize the use of nmh in the names is that I think it would be very cool to merge the two branches in the future. Maybe the the next nmh release could be MH 7.0. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: Working on the install-mh change questions
Jon, > I'd waste less if there was less code Refactoring code so that there is less of it is a good thing. Throwing away defensive copies or code that does something that could "never happen" that is under someone else's control is a bad thing. If the code that could "never happen" isn't within a few lines of your current code, it could (and will) happen. It is not "slow and sloppy" but absolutely vital. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: nmh 1.1 release canidate uploaded
Glenn Burkhardt <[EMAIL PROTECTED]> wrote: > Ken Hornstein <[EMAIL PROTECTED]> wrote: > > > Everyone, > > > > I've created a nmh 1.1 release canidate. You can get it from: > > > > http://savannah.gnu.org/download/nmh/nmh-1.1-RC1.tar.gz > > What's the difference between this release and the one I picked (and have > been using since then) in July? Good question. Unfortunately, Savannah doesn't seem to provide the same Files section as does Sourceforge which organizes release notes and changelogs together with the release. It just points to a big ftp directory. In the MH-E project, my "release notes" are the README file which is short and says which versions of Emacs are supported, how to install MH-E, and where to get more help and documentation. I don't actually show the actual ChangeLog, but distill the best bits. It looks like the Emacs' NEWS file. On Savannah, we could do one of two things (or a combination). We could create README and a NEWS files. The README would include the installation notes (which in nmh's case might point to an INSTALL file within the distribution) and the NEWS file would be a reverse chronological listing of new features and bug fixes: NEWS README nmh-1.1-RC1.tar.gz Or, we could associate a README and a NEWS file with each release: nmh-1.1-RC1.NEWS nmh-1.1-RC1.README nmh-1.1-RC1.tar.gz Or, a combination thereof (I think this would work best in this case): README nmh-1.1-RC1.NEWS nmh-1.1-RC1.tar.gz To see where I'm coming from, go to: https://sourceforge.net/projects/mh-e/ Look down to the "Latest File Releases" section and and click on the book for the mh-e package. When you do that, you'll see the Notes (which comes from the README in the distribution) and the Changes (which comes from the file MH-E-NEWS in the distribution). The only reason we use the name MH-E-NEWS instead of NEWS is because we install MH-E into GNU Emacs, and it wouldn't be such a great idea to overwrite the Emacs NEWS file ;-). -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: Working on the install-mh change questions
Jon Steinhart <[EMAIL PROTECTED]> wrote: > 5.There's code that removes a trailing / from mypath if mypath is more > than one character long. Seems completely unnecessary; the definition > of path names means that // is interpreted as /. And if that wasn't > the case, this code wouldn't catch multiple trailing slashes anyway. I'm not familiar enough with the MH code to know about the other issues, but with this one, if the path is shown to the user in any way, at worst this is a nice cosmetic fix. At best, it saves the user from opening the wrong file if he cut and pastes the path into Emacs, for example. Thanks for taking the time to clean things up. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: Appropriateness of new program/feature
Jerry Peek [EMAIL PROTECTED]; wrote: > ": aborting: can't read . Check your > MH environment variable (if any) or run install-mh to install nmh." Good idea. > Comments, anyone? Would this change break any front-end programs > (mh-e, etc.) that somehow depend on the prompts that install-mh now > prints by default? Fascinating. MH-E 5.0.2 ran install-mh for you, but I notice that the beta for MH-E 7.0 (mh-e.sourceforge.net) prints a mysterious message (Can't find paths). Whoops, I guess that's something we never checked while putting out this version. In any case, MH-E development is active enough these days that we could easily recover from any changes to nmh in this department. Don't let us stop you. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: Using web browser mail agent as nmh message viewer
While traveling, I used mail.yahoo.com and popped my mail from mail.newt.com. What I would have preferred was to use www.newt.com to access my MH folders directly via a web interface (since an Internet cafe is more likely to have a browser than an ssh client) as well as compose mail. I assume that mhonarc is one tool in the toolkit, anything else? -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: A tribute to nmh
And while I was traveling, a mail loop gave me a 2 GB mail file which I pruned in minutes with inc; rmm `pick -from mailer-daemon`; -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
