wish $edit_charset

> This is a feature request.
> 
> There should be a variable editor_charset, which determines the
> charset in which an external editor reads and writes files. At the
> moment it is always the same as the terminal encoding ($charset). 
> 
> This feature is e.g. motivated by the following situation:
> 
> Many users may have an unicode-editor (as yudit or emacs+mule-ucs),
> but do not want to configure their mutt terminal for UTF-8 support
> (because this is a little tricky and requires recompilation of mutt in
> most cases).

$ grep editor ~/.muttrc
set editor="LC_CTYPE=en_IE.ISO8859-15 vi"
$

Lars Hecking <lhecking@nmrc.ie>:

> > This is a feature request.
> > 
> > There should be a variable editor_charset, which determines the
> > charset in which an external editor reads and writes files. At the
> > moment it is always the same as the terminal encoding ($charset). 
> > 
> > This feature is e.g. motivated by the following situation:
> > 
> > Many users may have an unicode-editor (as yudit or emacs+mule-ucs),
> > but do not want to configure their mutt terminal for UTF-8 support
> > (because this is a little tricky and requires recompilation of mutt in
> > most cases).
> 
> $ grep editor ~/.muttrc
> set editor="LC_CTYPE=en_IE.ISO8859-15 vi"
> $

We're assuming the editor cannot be made to use the same encoding as
Mutt's $charset, so you need to set editor=some_script like:

#!/bin/sh
iconv -f iso-8859-1 -t utf-8 < $1 > $1.utf
yudit $1.utf
iconv -f utf-8 -t iso-8859-1 < $1.utf > $1

So it can be solved using $editor, and it's probably not worth adding
yet another variable to Mutt.

Edmund

> > Many users may have an Unicode-editor (as yudit or emacs+mule-ucs),
> > but do not want to configure their mutt terminal for UTF-8 support
> > (because this is a little tricky and requires recompilation of mutt in
> > most cases).

> set editor="LC_CTYPE=en_IE.ISO8859-15 vi"

This is not exactly a solution to my problem. A user may e.g. wish to
enter Japanese characters, which he can't enable in an standard
terminal. But if the editor has another charset (e.g. UTF8 or JIS), he
can type the mail in Japanese and look at it using 'view-mailcap',
provided an properly configured .mailcap.

This is especially useful for people who have occasionally
correspondence in foreign scripts, but whose biggest part of mails is
latin1 encoded.

DniQ.

> #!/bin/sh
> iconv -f iso-8859-1 -t utf-8 < $1 > $1.utf
> yudit $1.utf
> iconv -f utf-8 -t iso-8859-1 < $1.utf > $1

This is still not what I had in mind. I thought of an user, who
*wants* to use the capabilities of unicode or another big encoding,
and accepts that some characters may be not be displayable in mutt,
because he can read the mail in an external viewer in cases of need.

Suppose you want to compose emails which contain both french and
hungarian (think of an e-mail language course). You can't achieve this
with a normal 8-bit encoding, so you will have to type it with an
unicode editor, but you still can read the mail in mutt, because the
biggest part of the mail is ASCII, thus the text is still intelligible
with the latin1/latin2 characters replaced by a box. And if you want
to see it with right diacritics, you may look at it using
'view-mailcap'.

I do further think, that the separation of terminal charset and editor
charset is quite a natural one in our days of GUIs, because the editor
often does not run in the same terminal as mutt any more.

DniQ.

merge 433 1317
merge 676 965

Some control of the interaction between mutt and external editor is certainly needed, 
see http://wiki.mutt.org/?MuttFaq/Charset

Deduppe unform. Add to notifieds:
 - Dominique Unruh, reporter of Flea #433 "There should be a
variable editor_charset".
 - Kurt Roeckx, reporter of Debian #384642 "Editing mails in
UTF-8 on a latin1 terminal".

Alain.

This should probably be regarded as a bug as when replying, the quoted message may be modified when converted to the local charset. I think it is important to keep it unmodified though the user who replies cannot necessarily read it completely (in particular when the reply is a follow-up to a mailing-list).