I also use utf-8 as system locale and charset in muttrc. But I have
no problem in default case-insensitive search. eg. ~f kevin can match
Kevin.
--
regards,
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys
On Fri, 30 Oct 2009, Kevin Kammer wrote:
$ LC_ALL=C mutt
AFAIK, gnu sort perform case sensitive sort for POSIX or C locale,
compare output from
ls |sort # case insensitive in my locale
ls |LC_ALL=C sort# case sensitive
--
regards,
On Fri, Oct 30, 2009 at 08:43:21AM -0500, Kyle Wheeler wrote:
Are you using your system's regex library, or the one that comes with
mutt? It's possible that your system's regex library has a bug in it
(and it would be nice to eliminate that before blaming mutt for the
problem).
~Kyle
# case sensitive
Yes, ls |sort executed in my shell, with the default UTF-8 locale, is
case insensitive. Regex searches in the shell or other programs behave
as expected (i.e. lower-case search patterns are insensitive, whereas
mixed-case patterns only match results with the same capitalization
Horacio Sanson wrote:
I want to print emails from within mutt but when the emails contain Japanese
text in UTF-8 encoding I get very bad results and wasted paper.
For printing Japanese text I use the command:
cat JapaneseDoc.txt | paps | lpr
Here the paps converts the japanese text
I want to print emails from within mutt but when the emails contain Japanese
text in UTF-8 encoding I get very bad results and wasted paper.
For printing Japanese text I use the command:
cat JapaneseDoc.txt | paps | lpr
Here the paps converts the japanese text to postscript that lpr can
them with folder-hooks. It took quite some time to
find out the right strings to match the folders, but I could solve that.
Now the following problem occurs. The signature files start with the
UTF-8 byte order mark, which is no problem for current editors (Vim,
Notepad++) and Thunderbird itself. My
On Fri, Aug 07, 2009 at 03:52:10PM +0200, Alexander Dahl wrote:
24 feffAlexander Dahl, Staff Engineer
This is the same signature you should see below and you should also find
this special character in it.
Is it possible to use this character in the body of a mail? I'm not
seeing a
: this is UTF-8. But that's not the whole story.
Since Unicode defines multi byte encodings it is also necessary to know
which byte of the character comes first, that's why it's called Byte
Order Mark. Perhaps you have heard of the difference between big endian
and little endian. This is necessary
On Fri, Aug 07, 2009 at 08:11:58AM -0600, lee wrote:
Is it possible to use this character in the body of a mail? I'm not
seeing a special character in the signature.
Yes, it's just that this one has zero width and there mutt ignores
it (as it does for 0x200b).
Rocco
utf-8, thus no BOM and no
indication of character set and encoding. In that the case the user is
responsible for this. In my opinion, this counts for utf-8 files, too.
You see it is not really necessary in my signature files, at least if I
edit them on UTF-8 linux systems only (that's not the case
Hi,
The do it... :) In mutt, you can even set $signature to a pipe, i.e.
a script that gets the signature as argument and prints it with BOM:
set signature=script.sh signature|
That's what I did now, wrote a script strip-bom.pl which removes the BOM
from the beginning of the signature
Hello Chris,
On Wednesday, March 19, 2008 at 12:53:07 +, Chris Green wrote:
'locale' reports:-
| LANG=en_GB.utf8
| LC_CTYPE=en_GB.utf8
| LC_COLLATE=C
You can remove the $LC_CTYPE variable from your environment: The
$LANG var suffices to give the very same result. Define individual
On Sun, Mar 23, 2008 at 12:14:01PM +0100, Alain Bench wrote:
Hello Chris,
On Wednesday, March 19, 2008 at 12:53:07 +, Chris Green wrote:
'locale' reports:-
| LANG=en_GB.utf8
| LC_CTYPE=en_GB.utf8
| LC_COLLATE=C
You can remove the $LC_CTYPE variable from your environment: The
On 19 Mar 2008 10:40 +, by [EMAIL PROTECTED] (Chris G):
in mutt I have set charset=utf-8.
What am I doing wrong?
There was a discussion about this just recently, starting with
message-ID [EMAIL PROTECTED]. In short, first off, try
to avoid setting $charset and see what that does
On Wed, Mar 19, 2008 at 11:03:14AM +, Michael Kjorling wrote:
On 19 Mar 2008 10:40 +, by [EMAIL PROTECTED] (Chris G):
in mutt I have set charset=utf-8.
What am I doing wrong?
There was a discussion about this just recently, starting with
message-ID [EMAIL PROTECTED]. In short
On Wed, Mar 19, 2008 at 12:13:39PM +, Chris G wrote:
On Wed, Mar 19, 2008 at 11:03:14AM +, Michael Kjorling wrote:
On 19 Mar 2008 10:40 +, by [EMAIL PROTECTED] (Chris G):
in mutt I have set charset=utf-8.
What am I doing wrong?
There was a discussion about this just
use a font for utf8-encoding?
You can test it like this: put a pound sign into a file and be sure, that
this file is utf-8 encoded. Then try cat file in the terminal.
To get the right font in my xterm, I have the following line in my
.Xdefaults:
xterm*font: -adobe-courier-bold-r-*--20
? instead of the
correct characters.
Hello Chris,
Does the terminal use a font for utf8-encoding?
You can test it like this: put a pound sign into a file and be sure, that
this file is utf-8 encoded. Then try cat file in the terminal.
To get the right font in my xterm, I have the following
then when I
view the E-Mail using mutt I see reverse video ? instead of the
correct characters.
Hello Chris,
Does the terminal use a font for utf8-encoding?
You can test it like this: put a pound sign into a file and be sure, that
this file is utf-8 encoded. Then try cat file
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday, March 19 at 12:53 PM, quoth Chris G:
It seems to me that mutt is actually *encoding* the characters wrong
(or it's using a library that's doing that) as even if I save the
sentmail copy of a message with (for example) pounds signs
On Wed, Mar 19, 2008 at 09:47:41AM -0400, Ken Weingold wrote:
On Wed, Mar 19, 2008, Chris G wrote:
Yes, that's it, *everything* was actually alright except my editor
wasn't entering UTF-8 pounds signs (etc.). The rest of the system
just did its best to work around the resulting confusion
(as in correctly encoded as utf-8 by my editor)
pound signs:-
��
Well, not right as observed here,
screen capture: http://wahoo.no-ip.org/~pat/ChrisG.pound.jpg
Mutt 1.5.13 (2006-08-11)
openSUSE 10.1 x86_64
xterm
locale
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
On 19 Mar 2008 14:14 +, by [EMAIL PROTECTED] (Chris G):
Here are some incorrect pound signs:-
?�
This shows up to me (on a thoroughly UTF-8 system) as 56 undisplayable
glyps, one question mark, and one more undisplayable glyph
:-
?�
Here are some correct (as in correctly encoded as utf-8 by my editor)
pound signs:-
��
Well, not right as observed here,
screen capture: http://wahoo.no-ip.org/~pat/ChrisG.pound.jpg
Mutt 1.5.13 (2006-08-11)
openSUSE 10.1
On 19.03.08 14:37:58, Michael Kjorling wrote:
On 19 Mar 2008 14:14 +, by [EMAIL PROTECTED] (Chris G):
Here are some incorrect pound signs:-
?�
This shows up to me (on a thoroughly UTF-8 system) as 56 undisplayable
glyps
the correct utf-8 encoding).
--
Chris Green
this that is the fundamental problem (apart from getting my
editor to enter the correct utf-8 encoding).
Not even that, something has set the charset to us-ascii.
Does something, somewhere *guess* the character set from the stream of
characters it sees?
I'll send a couple more messages to the list, one with some
--
Chris Green
* Chris G [EMAIL PROTECTED] [03-19-08 11:07]:
this one displays correctly,
Content-Type: text/plain; charset=iso-8859-1
--
Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711
http://wahoo.no-ip.org
On 19 Mar 2008 15:02 +, by [EMAIL PROTECTED] (Chris G):
Does something, somewhere *guess* the character set from the stream of
characters it sees?
Mutt looks at the message and picks the first charset from
$send_charset that allows an exact encoding.
On 19 Mar 2008 15:04 +, by [EMAIL PROTECTED] (Chris G):
These came through correctly.
--
Michael Kjörling .. [EMAIL PROTECTED] .. http://michael.kjorling.se
* . No bird soars too high if he soars with his own wings . *
*
# Default: us-ascii:iso-8859-1:utf-8
#
#
# A list of character sets for outgoing messages. Mutt will use the
# first character set into which the text can be converted exactly.
# If your ``$charset'' is not iso-8859-1 and recipients may not
# understand UTF-8, it is advisable to include in the list
On Wed, Mar 19, 2008 at 11:09:46AM -0400, Patrick Shanahan wrote:
* Chris G [EMAIL PROTECTED] [03-19-08 11:07]:
this one displays correctly,
Content-Type: text/plain; charset=iso-8859-1
Yes, it does for me too, as you can
0xBD
Here are some correct (as in correctly encoded as utf-8 by my editor)
pound signs:-
Those are also all the same three bytes: 0xEF 0xBF 0xBD
That *looks* like valid utf-8.
For a quick tutorial in three-byte utf-8, the way three-byte letters
are encoded (in binary) is like
that, so what is setting it to that, incorrectly! I suspect that it's
probably this that is the fundamental problem (apart from getting my
editor to enter the correct utf-8 encoding).
Not even that, something has set the charset to us-ascii.
Does something, somewhere *guess* the character
On Wed, Mar 19, 2008 at 03:14:43PM +, Michael Kjorling wrote:
On 19 Mar 2008 15:02 +, by [EMAIL PROTECTED] (Chris G):
Does something, somewhere *guess* the character set from the stream of
characters it sees?
Mutt looks at the message and picks the first charset from
$send_charset
=iso-8859-1
Yes, it does for me too, as you can see I'm getting very confused by
all this now!
try:
set send_charset=us-ascii:iso-8859-1:iso-8859-15:windows-1252:utf-8
--
Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711
http://wahoo.no-ip.org Photo Album
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday, March 19 at 03:29 PM, quoth Chris G:
On Wed, Mar 19, 2008 at 03:14:43PM +, Michael Kjorling wrote:
On 19 Mar 2008 15:02 +, by [EMAIL PROTECTED] (Chris G):
Does something, somewhere *guess* the character set from the stream of
On Wed, Mar 19 2008, Chris G wrote:
Only the subject line is wrong ;)
Peter
--
http://pmrb.free.fr/contact/
that is fed into it to be? If I feed
it text in utf-8 the surely it just stays that way - though thinking
about it this *doesn't* seem to be what's happening.
If I understand then mutt is trying to choose the 'least complex'
charset that it can. So even if my system is locally all set up to
work in utf
has doesn't need to be dictated by
the encoding your system uses. My own system is utf-8 since a long time,
but mails are always sent out in the smallest encoding (us-ascii,
latin1, utf-8 ... in that ordeR)
Thats actually quite common among good mail clients.
Andreas
--
If you think last Tuesday
that were seen correctly by
everyone on the mutt list (including me) were read from a file I had
created directly from the command line and checked to see if it was
proper utf-8 which it was.
It's getting pound signs typed into my editor recognised by mutt as
pound signs that is the issue. I think
exactly., what does this mean?
For example, let's take the Euro symbol. If your email includes the
euro symbol, mutt needs to decide which charset to use. If your
send_charset is us-ascii:iso-8859-1:utf-8, what happens? First, mutt
uses iconv to try and convert your email into us-ascii. Since
and picks the first charset from
$send_charset that allows an exact encoding.
http://www.mutt.org/doc/devel/manual.html#send-charset
Well it's not a very good way of guessing then! :-)
PS: The mail with those strange characters is also encoded properly, its
valid UTF-8, just that your
Hello Magnus,
On Tuesday, April 17, 2007 at 16:43:37 +0200, Magnus Cappelen Solvang wrote:
If I press r for Reply on a mail with norwegian characters - half the
times vim will show the correct characters, while they will be garbled
the rest of the times. r for Reply, :q to quit without
Quoting Alain Bench ([EMAIL PROTECTED]):
[...]
| Just a guess: You use a random signature, sometimes containing
| accented characters written in Latin-1.
Spot on, Alain! I'm impressed! Some of the norwegian signatures contained
special characters.
[...]
| If it's the problem, the
I'm using vim as my editor, and I'm pretty sure that everything is OK with
utf-8 in vim. file on files created by vim in the console show e.g:
filename: UTF-8 Unicode text
...and my norwegian characters show as expected on my newly installed
Fedora Core 6-server. I'm reading mail from
Hello Ismael,
On [Wed, 10.01.2007 18:13], Ismael Valladolid Torres wrote:
What I am trying to achieve is for emacs to open any new file or
existing file editing it in the UTF-8 language environment (u must
be showed in the lower left corner of emacs). This works for any file
except when I go
with
something as:
(add-hook 'mail-mode-hook '(setq buffer-file-coding-system 'mule-utf-8))
I have the following set in emacs and this seems to work for me. I
have no idea if it is related to your issue or not. This is just a
quick brainstorm idea.
(prefer-coding-system 'utf-8)
Bob
I am using mutt in utf-8 mode (mutt-utf8_1.4.0-4_i386.deb with
LC_CTYPE=sv_SE.UTF-8). Together with xterm and vim this works very
well. Both european and asian letters show up correctly (in the same
terminal) as long as they have the correct mime charset.
However, if the charset is not defined
The Mac OS X Terminal does not have much support for anything but
vt100, so the mutt threading has to be set to with ascii_chars. In
the next release of OS X, 10.2, the terminal has UTF 8 support. I
don't know much about this, and the mutt manual says that threading by
default uses ACS
On Thu, Jul 18, 2002 at 02:16:03PM -0400, Ken Weingold wrote:
The Mac OS X Terminal does not have much support for anything but
vt100, so the mutt threading has to be set to with ascii_chars. In
the next release of OS X, 10.2, the terminal has UTF 8 support. I
don't know much about
, why doesn't mutt enable utf-8 natively and by
% default ? Are there any adverse affects if that were to happen ?
You mean override the LC_* variables? I should think that would be
obvious, so perhaps I've misunderstood your question.
If someone would like to use utf-8 irrespective
Hi!
On Thu, Jun 13, 2002 at 09:07:13AM -0700, Tim Freedom wrote:
If someone would like to use utf-8 irrespective of the locale
setting, he/she ought to be able to do that, no ? There are lots of
Maybe I don't understand you, but how can a textmode application like
mutt or vim, which depends
I have a message that is in UTF-8, it is marked as such in the
header (charset=utf-8); I have $charset set to utf-8 in my
muttrc, and I'm using a UTF-8 terminal emulator. But mutt
is doing something to the message such that it does not show
up properly in the internal pager; I get garbage
I should have mentioned that I'm using mutt 1.4i.
On Thu, Jun 13, 2002 at 03:50:09PM -0400, Mark J. Reed wrote:
I have a message that is in UTF-8, it is marked as such in the
header (charset=utf-8); I have $charset set to utf-8 in my
muttrc, and I'm using a UTF-8 terminal emulator. But mutt
On Thu, Jun 13, 2002 at 03:50:09PM -0400, Mark J. Reed wrote:
it shows up fine, but I don't want to use the functionality of
^^^
And I meant lose there. :)
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL
_anything_ you will
be able to view/compose/etc a utf-8 (both in graphical mode and/or in
a UTF-8 terminal emulator). So what happens if you start that same
vim binary on a non-UTF-8 xterm ? vim is smart to note that UTF-8 is
not-supported and beep at yeah. That's pretty much all I'm advocating
Mark --
You should go back and read Tim Freedom's utf-8 thread if he doesn't
respond to you first (now that he has the answers and can contribute
back to the community). It probably has to do with your locale settings.
See his messages of Jun 9th and forward in the archives.
HTH HAND
:-D
On Thu, 13 Jun 2002 22:15:18 +0200,
Stephan Seitz wrote:
On Thu, Jun 13, 2002 at 11:32:54AM -0700, Tim Freedom wrote:
vim-6.1+ and compile it. Then without having to do _anything_ you will
be able to view/compose/etc a utf-8 (both in graphical mode and/or in
a UTF-8 terminal emulator
Tim Freedom wrote:
[snip snip]
Once I invoke mutt and view my sample mbox with utf-8 characters in it
(which a friend is able to see without a problem on FreeBSD) I see some
correct glyphs and lots of octals,
\207
\206\203
so in all, there are a few correct glyphs
of curiosity, why doesn't mutt enable utf-8 natively and by
% default ? Are there any adverse affects if that were to happen ?
You mean override the LC_* variables? I should think that would be
obvious, so perhaps I've misunderstood your question.
Glad to hear you got it all solved!
HAND
:-D
Tim --
...and then Tim Freedom said...
%
% Tim Freedom wrote:
%
...
%
% Once I invoke mutt and view my sample mbox with utf-8 characters in it
% (which a friend is able to see without a problem on FreeBSD) I see some
% correct glyphs and lots of octals,
%
%\207
%
%\206\203
I'm having problems displaying utf-8 characters.
I compile with the following info,
uname -a : SunOS droid 5.7 Generic_106541-08 sun4u
gcc -version : 2.95.2
$ ./configure --prefix=/tools/mutt
--with-iconv=/tools/libiconv
--enable-locales-fix
I'm having problems displaying utf-8 characters in mutt-1.4.
I compile with the following info,
uname -a : SunOS droid 5.7 Generic_106541-08 sun4u
gcc -version : 2.95.2
$ ./configure --prefix=/tools/mutt
--with-iconv=/tools/libiconv
--enable-locales
I recently downloaded mutt-1.3.28i hoping to play with the utf-8 support;
I'm having a few problems in this area, so bare with me - here's what I
did and what's happening.
Some background info,
uname -a : SunOS max 5.7 Generic_106541-08 sun4u
gcc -version : 2.95.2
% ./configure
:50 +0800
From: Charles Jie [EMAIL PROTECTED]
To: mutt [EMAIL PROTECTED]
Subject: How to display texts encoded in UTF-8?
Hi,
My linux box has locale zh_TW.Big5 (Traditional Chinese). I have the
following settings in .muttrc and it works well in most of the cases.
set charset
Date: Sat, 2 Mar 2002 08:34:50 +0800
From: Charles Jie [EMAIL PROTECTED]
To: mutt [EMAIL PROTECTED]
Subject: How to display texts encoded in UTF-8?
Hi,
My linux box has locale zh_TW.Big5 (Traditional Chinese). I have the
following settings in .muttrc and it works well in most
Hi,
My linux box has locale zh_TWBig5 (Traditional Chinese) I have the
following settings in muttrc and it works well in most of the cases
set charset=big5
charset-hook big5# for the mail missing 'charset'
But from time to time, I may get mail from MUA that encodes in UTF-8
On Mon, Jan 07, 2002 at 08:50:16PM +0100, Michael Wagner wrote:
On Sonntag, 06. Jan. 2002 at 20:53:24, MuttER wrote:
On Tue, Dec 18, 2001 at 08:30:05PM +0530, Prahlad Vaidyanathan wrote:
mailcap
text/html; w3m -T text/html %s
/mailcap
You could also add a 'copiousoutput' at
On Sonntag, 06. Jan. 2002 at 20:53:24, MuttER wrote:
On Tue, Dec 18, 2001 at 08:30:05PM +0530, Prahlad Vaidyanathan wrote:
mailcap
text/html; w3m -T text/html %s
/mailcap
You could also add a 'copiousoutput' at the end of that, and set
auto_view text/html in your muttrc to put
On Tue, Dec 18, 2001 at 08:30:05PM +0530, Prahlad Vaidyanathan wrote:
Hi,
On Tue, 18 Dec 2001 Stephan Seitz spewed into the ether:
[-- snip --]
PS: How do you call w3m to display html mails?
mailcap
text/html; w3m -T text/html %s
/mailcap
You could also add a 'copiousoutput' at
click here for
more information but you can't klick or see the address.
lynx produces footnotes for every HREF link, but it doesn't work well
in an utf-8 environment.
Shade and sweet water!
Stephan
--
| Stephan Seitz E-Mail: [EMAIL PROTECTED] |
| WWW: http
On Thu, 20 Dec 2001, Stephan Seitz wrote:
lynx produces footnotes for every HREF link, but it doesn't work well
in an utf-8 environment.
I ought to write a lynx faq... (the utf-8 stuff works well enough with
current code compiled against libncursesw).
--
T.E.Dickey [EMAIL PROTECTED]
http
, but the mutt pager
deletes the HREF links, so you only see something like click here for
more information but you can't klick or see the address.
lynx produces footnotes for every HREF link, but it doesn't work well
in an utf-8 environment.
It's not the mutt pager but w3m that's hiding the HREF
Hi!
On Mon, Dez 17, 2001 at 08:37:24 +0100, Cristian wrote
Accepts UTF-8 only if you set $LC_ALL correctly. My point was that all
the programs I listed worked fine after I just set $LANG.
vim works fine here. If I set LANG=de_DE.UTF-8 the other variables get
the same value as well.
Normaly I
Hi,
On Tue, 18 Dec 2001 Stephan Seitz spewed into the ether:
[-- snip --]
PS: How do you call w3m to display html mails?
mailcap
text/html; w3m -T text/html %s
/mailcap
You could also add a 'copiousoutput' at the end of that, and set
auto_view text/html in your muttrc to put w3m's output
Hi!
On Sat, Dec 15, 2001 at 04:00:03PM +0100, Cristian wrote
browsers: w3m-m17n (with autoconversion from `any' other character set),
lynx (works with UTF-8 and iso-8859-1, at least)
Strange, never w3m nor lynx can correctly display
http://fsing.fs.uni-sb.de/~stse/manga.html
-JP.
In order to view UTF-8, you need to get the w3m-m17n patch from
http://www2u.biglobe.ne.jp/%7Ehsaka/w3m/
w3mmee is an independent patch for the same purpose.
Lynx has a setting for this. My ~/.lynxrc contains the line,
character_set=UNICODE (UTF-8)
Though I hardly use it now that there's w3m
character
sets Shift_JIS, EUC_JP, and ISO-2022-JP.
In order to view UTF-8, you need to get the w3m-m17n patch from
http://www2u.biglobe.ne.jp/%7Ehsaka/w3m/
w3mmee is an independent patch for the same purpose.
Lynx has a setting for this. My ~/.lynxrc contains the line,
character_set=UNICODE (UTF
Hi Mutt users,
now that Robert has brought up the issue, I'd like to describe my own
adventures in the field of Unicode/UTF-8. Short answer, try setting:
export LC_ALL=de_DE.UTF-8
export LANG=de_DE.UTF-8
(bash syntax). If you want your apps to `speak' German. Replace de_DE
by en_GB or en_US
On 2001-10-31 13:47:01 -0500, Matej Cepl wrote:
LANG=cs_CZ
SYSFONT=lat2-16
SYSFONTACM=iso02+euro
UNIMAP=iso02
Everything seems to work well, except for mutt (and mc, but
that's another question). When I set charset to utf-8, it doesn't
work on accented characters (obviously, it doesn't make utf
Hi,
I have set up Unicode support on my console (RedHat 7.0) with the
following in /etc/sysconfig/i18n:
LANG="cs_CZ"
SYSFONT="lat2-16"
SYSFONTACM="iso02+euro"
UNIMAP="iso02"
Everything seems to work well, except for mutt (and mc, but
that's anothe
On 2000-06-29 19:36:24 +0200, Marius Gedminas wrote:
Can Mutt 1.2 handle UTF-8?
Only on the receiving side.
When I have $charset="iso-8859-13", and
$send_charset="utf-8", bad things happen. BTW, I have
glibc 2.1.3.
For heavily improved utf-8 support (includ
On Fri, Jun 30, 2000 at 10:42:26AM +0200, Thomas Roessler wrote:
On 2000-06-29 19:36:24 +0200, Marius Gedminas wrote:
Can Mutt 1.2 handle UTF-8?
Only on the receiving side.
OK. Maybe this should be documented before 1.2.3 goes out?
For heavily improved utf-8 support (including the use
On 2000-06-30 13:46:22 +0200, Marius Gedminas wrote:
I didn't know Mutt-1.3.x supported utf-8 display
without additional patches.
Most of the changes made to the unstable branch so far
were precisely about that.
I guess it still needs a utf-8 enabled slang, right?
Yes.
Can Mutt 1.2 handle UTF-8? When I have $charset="iso-8859-13", and
$send_charset="utf-8", bad things happen. BTW, I have glibc 2.1.3.
Marius Gedminas
--
Hoping the problem magically goes away by ignoring it is the "microsoft
approach to programming&quo
(1) Is it possible to run mutt in an xterm (or eterm or whatever) that
understands UTF-8 and thus read UTF-8 e-mail that contains a wacky
mixture of UTF-8-encoded characters? If so, is there a HOWTO that
explains what to do?
(2) I received e-mail which had UTF-8 in the headers, like
On 1999-09-28 15:31:33 +0200, Edmund GRIMLEY EVANS wrote:
(2) I received e-mail which had UTF-8 in the headers, like this:
From: "Kalle XXXä" [EMAIL PROTECTED]
That's a 2-byte encoding of auml;. Is there an RFC that permits or
forbids this? Should this really have been some
(2) I received e-mail which had UTF-8 in the headers, like this:
From: "Kalle XXXä" [EMAIL PROTECTED]
That's a 2-byte encoding of auml;. Is there an RFC that permits or
forbids this? Should this really have been something like:
rfc822 only allows 7bit in the hea
101 - 191 of 191 matches
Mail list logo
