I'm not a w3m user but I think that formats the HTML into text? I was
interested in a base64 windows-1252 text/plain staying as text/plain but
utf-8 and 8-bit. IOW, ideal for grep.
Me too, but probably that would be a different tool?
Personally I care about the message in it's most usable
Backup (,) message files aren't, either, and I view
the originals as similar in that respect. With the Message-ID
files, the original can be found with an easy grep.
Me too, as I won't keep them anyway.
But those who actually want to keep originals for something
other than just debugging:
Ralph Corderoy ra...@inputplus.co.uk:
AIUI we know of two emails that are broken. That doesn't seem enough to
warrant changing the code to not match the RFCs and opening the door a
bit more, encouraging further forgiveness of broken input. Members of
the list getting a duff email a week?
, and what
do we use as the MAIL FROM: message as part of the SMTP transaction?
Well, if we can't come up with anything better, then just whatever we
use now.
Some details:
I write this message without a From line, but
it will be filed in my outbox with a line of
From:Harald Geyer lam...@a.g4
Hi!
How are the debs maintained for Ubuntu and Debian? It would be good to
make sure they track our (your!) hard work.
I'm not sure how that works; does anyone happen to know?
Typically, the Debian Developer (maintaining the package) bundles
your released source with his own patches
Hi!
I observe that on one of my machines (IPv6 only system) every time I
run scan/show/repl (and probably others) a DNS query for the A record
of the machines hostname is sent. If a NXDOMAIN comes back everything is
fine, but if the request is lost then the command hangs for a few seconds.
This
Jon Steinhart j...@fourwinds.com:
The current behavior was the best idea that I had
at the time and nobody has said anything about it until recently. I don't
mind it changing, but I don't want to all of a sudden get complaints from
people who were counting on this behavior.
Well, I always
I have heard that a small change in the file mts/smtp/smtp.c
(of nmh 1.3) will change the mail port from 25 to 587 and get around
Verizon's port 25 block.
Does anyone have that change? Any help would be greatly appreciated.
Thank you.
I had the same problem (using a different ISP).
My
This is, I suppose, a bit controversial, since it's a UI change.
But, combined with having pick write out numbers as it finds them
(uip/pick.c r1.15), this is insanely useful. You can 'pick
whatever | scan -' and interrupt it when you find what you're
looking for.
Yes, I think this would be
I still think that numeric folder names rise questions: Consider the
above example. cur = inbox/11100. What should refile next:22 +foo do?
Move the numeric folder? Leave a copy with the name ,1 around?
(Note that you can't have hardlinks to directories on the filesystems
I know.)
I just realized that you can do refile 1 + and it works perfectly well,
that is: It does the only consistent thing to do and puts the message
directly into ~/Mail
That is surely a bug.
Yes, I did expect an error message, but after thinking about it, I don't
want nmh to prevent me from
Hi!
I just realized that you can do refile 1 + and it works perfectly well,
that is: It does the only consistent thing to do and puts the message
directly into ~/Mail
Actually it seems that most commands work fairly well on + but there
is one anomaly: The current folder always gets set to
So what exactly are the plans for 2.0?
I think the more important question is: Which of the various plans that
people have, need a major effort before the can be released and which
things can drip in as they get done? For the later i think Jon's
approach of Do whatever you like to see! is just
How about:
441 12/18 Joel Uckelman (0) [Nmh-workers] mhshow: invalid QUO
442 12/18 Josh Bressers (1) Re: [Nmh-workers] mhshow: invalid
443 12/18 Paul Fox (1) Re: [Nmh-workers] mhshow: invalid
444 12/18 Joel Uckelman (2) Re: [Nmh-workers] mhshow: invalid
448
* Threading support. This is one of the obvious things missing from
nmh that just about all modern mailers support.
I'm not that sure about this. After all it's about e-mail not usenet.
I have something like
thread () {
pick -subject $1 -seq thread
Jerry I hope John Romine -- who did MH maintenance at UC Irvine for
Jerry years -- won't mind my repeating something he mentioned to me
Jerry years ago. He was thinking about replacing mh-format -- that
Jerry is, code like:
Jerry %4(msg)%(cur)+%|
[CCing the Debian BTS]
You didn't include it in your list, but we perhaps ought to consider bug
9228:
https://savannah.nongnu.org/bugs/index.php?func=detailitemitem_id=9228
Anyone know the history of $mheditor? Can we just remove the reference
in the man page?
i only checked
Hi!
After discussing http://bugs.debian.org/143485 in detail a few month
ago and after discussing whether this is a vfork() issue, I finally had
the time to write a patch (attachment). Please have a look, whether this
seems sane (at least it fixes the original problem) and commit it to
CVS as you
| Ok, then this should be changed too, in case anybody wants to keep
| vfork().
Yes, that ought be changed, though in practice the one in question
should not really matter a lot, as it only happens if the exec fails,
which should ordinarily not happen.
But, aside from the fprintf,
| Obviously nmh does depend upon errno being unchanged, so it's the fault
| of nmh itself not linux.
That would be correct. In that case one might wonder though why the bug
is only observed under linux?
I don't see any reason why this bug should only be observable on linux other
than
| Hm, ok then this probably isn't that much of an issue as I thought before
| Is fprintf(stderr, ...) ok? After all it should be unbuffered?
No, stdio isn't OK, even if supposedly unbuffered. There's too much
state and context kept in there. Even if it works on one implementation
of
Paul Fox wrote:
can nmh decode UTF or otherwise-encoded headers? it's not that
Yes. See the decode function in the mh-format manual page. It has a few
limitations however. It doesn't use iconv or similar to convert headers
to the current encoding. So you need to use a
What do you consider a nice solution? I use the method as described
by Oliver (actually that's the default of the debian package). It works
satisfactory but unfortunately we have a wild mixture of latin1 and latin9
in europe (thanks to MS windows not being able or willing to adapt to
I guess it would be much easier und less prone to error to just
implement transcoding of messages through iconv instead of trying
to adapt the display on a per message basis.
In general, you *can't* do a good job of using iconv to mash things between
the various iso8859-* charsets.
I use nmh-1.0.4 in FreeBSD UNIX and have noticed that the
refile function occasionally eats a message. It moves it from one
folder to another all right, but what ends up in the receiving folder
is a file containing all 0xFF's.
Sounds like it fails to open it without noticing or
let's pass the torch to someone else. It would really be nice to have
something later than 1.04 included in Linux releases.
Actually 1.1 is included in debian unstable and testing and will be
part of the upcoming release in a few weeks. (Thanks to Nick
for his patience with that no so easy to
Hi!
Is there any sensible way to make 'repl -format' only quote the
text parts of a mime message? (It would be nice if it decoded them too.)
BTW: What is the status of nmh development? There seems to be no
cvs-activity for nearly a year. Is savannah still broken?
(I'm asking because I have
Is there any sensible way to make 'repl -format' only quote the
text parts of a mime message? (It would be nice if it decoded them too.)
There isn't a sensible way. I use a wrapper script (around vi) as my
message editor and the script includes the following:
if [[ -n $editalt ]]; then
28 matches
Mail list logo
