ra...@hep.wisc.edu writes:
The problem with that approach is that sometimes the text part just says
``There is no text part, use an HTML capable mail reader''. I'm seeing
more of them these days.
Really? I've been reading text/plain over text/html with EXMH for years and
recently with
*Please, no!* Conversion from any charset to utf-8 is possible, but
conversion back, according to user preferences, is not. People
start to use funny characters like non-breakable space and so on.
Unfortunately, we don't have unlimited development resources.
Here's my reading of the world:
-
Hi Ken,
- Conversion to Unicode is relatively simple. Conversion from Unicode to
some other character set isn't, depending on the character set (although
it would seem to me that converting from a non-breaking space to a regular
space is a no-brainer, but whatever).
I assumed nmh
I assumed nmh would convert to UTF-8, I'd edit a UTF-8 draft, and that's
what it would hand over to the MDA.
That works great if your locale is UTF-8 ... but what if it isn't? That's
where life gets complicated, and I think that means that it's just going
to suck for some people. Of course it
On 01/18/12 10:42, Tethys wrote:
Ken Hornstein writes:
So, I have some thoughts in this direction, but I'm wondering: what do
you want out of repl in terms of better MIME handling?
#1 is for base64 and quoted-printable to be decoded into UTF-8 before
being included in the reply body. #2
If both text/plain and text/html is available drop text/html
(maybe configurable ?)
You'd have to do this interactively, showing a snippet of each,
with the option to specify it on the command line.
Too many mismanaged mailing lists have nothing as their text/plain
content other than Your mail
Ken Hornstein writes:
*Please, no!* Conversion from any charset to utf-8 is possible, but
conversion back, according to user preferences, is not. People
start to use funny characters like non-breakable space and so on.
Unfortunately, we don't have unlimited development resources.
Here's
Shouldn't you guys also be talking about pick in connection with
messages containing Mime?
Norman Shapiro
798 Barron Avenue
Palo Alto CA 94306-3109
(650) 565-8215
n...@dad.org
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Ken Hornstein wrote:
- If we have to choose one, the only logical choice is Unicode (which in
practice means UTF-8; maybe UTF-16, but a trip through the format
code made me think that UTF-8 is probably the only real choice).
One very reasonable option would be to use the current locale
For English-speaking countries UTF-8, in majority, means ASCII,
they can see no difference. As an advantage they can use foreign
names like Moebius in original, this makes message more readable.
But I'm afraid they wouldn't be happy with message written in
Russian, Chinese or Korean.
Well, I
Shouldn't you guys also be talking about pick in connection with
messages containing Mime?
HOPEFULLY if I do things right, pick should Just Work.
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Ken Hornstein k...@pobox.com writes:
Shouldn't you guys also be talking about pick in connection with
messages containing Mime?
HOPEFULLY if I do things right, pick should Just Work.
But doesn't the pick API need new primitives, such all messages containing a
given mime type, all messages
Ken Hornstein k...@pobox.com writes:
But doesn't the pick API need new primitives, such all messages containing a
given mime type, all messages containing more than n mime types, etc? Or do
things like -search and --component somehow make those easy?
Sigh. One thing at a time, okay? Yes, pick
Hi Aleksander,
For English-speaking countries UTF-8, in majority, means ASCII, they
can see no difference.
I don't think that's the case. Even North Americans, who have $ in
ASCII, still find ‘ ’ “ ” and … cropping up, especially when services
automatically convert ` ' and And then
Thus spake Oliver Kiddle:
The limitations occur where e-mails use characters that can't be
displayed in the current locale but we can't do anything about that.
How likely is it that a message containing characters undisplayable in
the user's locale will be useful for the user? (This isn't
What do you mean by internal representation? Conversion from
any to utf-8, processing by the code and conversion back to the
original charset is really internal, transparent for the user.
Well, for example ... when you call fmt_scan(), what should the character
set be? Just one example. That's
Joel Uckelman writes:
Thus spake Oliver Kiddle:
The limitations occur where e-mails use characters that can't be
displayed in the current locale but we can't do anything about that.
How likely is it that a message containing characters undisplayable in
the user's locale will be
But restrict the entire nmh to utf-8 charset would cripple system.
How so, specifically? Plan9 has run a native UTF8-only mail environment
for ages (with a very MH-like mailstore, as well), and it's far from
crippled. It stores messages in their native format, and dynamically
converts
Couple of years ago emacs switch to internal coding in utf-8. I
had to stop using emacs and mh-e.
See, this is what I'm missing - why, exactly? I assume the problem was not
just philsophical.
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Guess it will take a while before better mime handling is implemented.
Not necessarily.
So, I have some thoughts in this direction, but I'm wondering: what do
you want out of repl in terms of better MIME handling?
--Ken
___
Nmh-workers mailing list
Hi Ken,
So, I have some thoughts in this direction, but I'm wondering: what do
you want out of repl in terms of better MIME handling?
All the text parts turned into UTF-8 and quoted would be a good start.
I can then trim down in vi as normal.
Cheers, Ralph.
So, I have some thoughts in this direction, but I'm wondering: what do
you want out of repl in terms of better MIME handling?
All the text parts turned into UTF-8 and quoted would be a good start.
I can then trim down in vi as normal.
Yeah, to me that would make things 100% better. That's
ken wrote:
So, I have some thoughts in this direction, but I'm wondering: what do
you want out of repl in terms of better MIME handling?
All the text parts turned into UTF-8 and quoted would be a good start.
I can then trim down in vi as normal.
Yeah, to me that would make things
On Tue, Jan 17, 2012 at 12:16, ra...@hep.wisc.edu wrote:
So, I have some thoughts in this direction, but I'm wondering:
what do
you want out of repl in terms of better MIME handling?
All the text parts turned into UTF-8 and quoted would be a good
start.
I can then
The problem with that approach is that sometimes the text part just says
``There is no text part, use an HTML capable mail reader''. I'm seeing
more of them these days.
Yeah, I've seen those occasionally but I'm willing to put that problem
off for a little while.
--Ken
25 matches
Mail list logo
