Hi,
When I forward a mail that consists of HTML parts and attachments, as an
rfc822 attachment, the mail is scrambled and messy, with base64 encoding
and all headers included.
My webmail client cannot make sense of these mail and neither can my
mh-e client.
I tried both forw without any
I noticed that en_US.UTF-8 appears in hardcoded form in the test cases.
Knowing that my system doesn't have it, I tried running the test cases
and, sure enough:
Unable to convert string →n̈
test/scan/test-scan-multibyte: 59: test: Illegal number:
test/scan/test-scan-multibyte: 63: test: Illegal
I noticed that en_US.UTF-8 appears in hardcoded form in the test cases.
Knowing that my system doesn't have it, I tried running the test cases
and, sure enough:
Unable to convert string ânÌ
test/scan/test-scan-multibyte: 59: test: Illegal number:
test/scan/test-scan-multibyte: 63: test:
1) on input (inc, slocal, etc), we convert to UTF-8 [1]
2) on output, we convert to whatever the environment wants.
3) Everything inside the code/disk-storage uses UTF-8.
Ditch stdio in favour of bio and we are 90% of the way there. Incorporate bio
in the build tree and we have no external
1) on input (inc, slocal, etc), we convert to UTF-8 [1]
So, I suggested that a while ago and I got pushback.
http://lists.nongnu.org/archive/html/nmh-workers/2012-01/msg00206.html
2) on output, we convert to whatever the environment wants.
3) Everything inside the code/disk-storage uses
On 2013-02-06, at 7:05 PM, Ken Hornstein wrote:
Ditch stdio in favour of bio and we are 90% of the way
there. Incorporate bio in the build tree and we have no external
dependencies.
[1] http://plan9.bell-labs.com/magic/man2html/2/bio
Hm. It's not clear to me how much bio helps here.
The thought is that we move to utf-8 as the native internal
representation of all internal content. The switch to bio makes that
happen.
I understand your first sentence. But I don't understand how bio makes
that happen as opposed to, say, sticking with stdio. I read the man
page and bio looks
