Re: [PATCH] <create-alias> writes to $alias_file in $config_charset
Hello Rocco and Thomas,
On Friday, August 4, 2006 at 12:43:33 +0000, Rocco Rutte wrote:
> your assumption that _current_ $config_charset is the encoding for the
> alias file may be wrong for some cases.
Of course: The user would have to set the appropriate runtime
$config_charset, say in muttrc, or at last just before <create-alias>.
There are some usage scenarios where this is workable and makes sense.
The simplest and more generic one is: User has rc files, aliases,
and files sourced from macros/hooks all in UTF-8. He sets
$config_charset=utf-8 at the beginning of muttrc, and never changes it.
This works read/write in all locales.
Equally simple but less generic: The same setup, but "utf-8"
replaced by something else (say Latin-1 for westerners). This works
read/write in most locales common for the given user.
I tested more complex situations, with multiple alias files, runtime
sourced rc files, having various charsets, some straight and some with
//TRANSLIT... And nearly always found one or more ways to make it work
OK. Much helped by $my_var temporary saving of $config_charset and
$charset. Flexibility is there, but... 2 points are annoying:
-1) Flexibility could/should be yet enhanced. Some ways are possible
but inelegant, or have uncomfortable constraints.
-2) Behaviour when things go wrong (even on user config error) should
be enhanced. I mean writing unconvertables ?-masked, thus silently
losing correct data entered and confirmed by the user, may not be the
sensiblest thing to do.
> My idea is to make mutt expect RfC2047-encoding in the alias file and
> let it convert to/from it for reading and writing.
I seem to remember this has been suggested long ago (by you Thomas?
Or was it EGE?), and rejected because the alias file is not purely
Mutt's private file. It has to be readable and writable by other apps,
even not specifically mail-oriented apps (so not 2047 aware), as well as
simply edited by the user. So aliases must be readable in clear text;
Encodings are excluded.
On Friday, August 4, 2006 at 14:48:15 +0200, Thomas Roessler wrote:
> Another thing to do might be to write an explicit "set content_charset
> into the aliases file -- not particularly nice, though.
This would work: Each muttrc/aliases line *can* be in a different
charset. But for ease of editing, we prefer to keep a file fully in one
charset only.
Other idea: Have multiple aliases files, with charset extensions.
Like ~/.mutt/aliases.iso-8859-1, aliases.utf-8, and so on. Begin them
with the "set config_charset=..." appropriate for sourcing them. And
<create-alias> autoselects the good file, proposes it to user's
confirmation, and writes it in the extension's charset.
The target charset could be $charset (no conversion). Or
$config_charset (under user control). Or determined by a new
$send_charset-like mechanism: 1st minimal and sufficient charset (no:
unjustifiably useless sophistication).
Optionally, let Mutt create a new aliases file if the needed charset
extension didn't exist yet. In this case, write a "set config_charset="
statement as first line.
Pros: Flexible. Cons: Could lead to dozens of files difficult to
follow and maintain. Steals too much user control. Source $alias_file.*
at once is not possible, nor easy, and would catch unwanted aliases.bak
Headaches if the user already has multiple aliases.friends,
aliases.work, and such.
And what to do if the prompted user forces a filename with an
insuficient charset? Silently mask? Warn and mask? Warn, ask
confirmation, and mask? Error and reprompt filename?
I'm unsure if the expected flexibility benefit is really worth the
efforts and added complexity... 1 hour ago it seemed to me a good idea;
But after writing this mail: Bof.
To illustrate what's doable right now, I'm experimenting a variation
around my production setup, with a main Latin-1 muttrc sourcing 4 alias
files in 3 other charsets. Roughly:
| set charset=//TRANSLIT # I want transliterated aliases
|
| set config_charset=iso-8859-2
| source ~/.mutt/aliases.latin-2 # people from east europe
|
| set config_charset=iso-8859-9
| source ~/.mutt/aliases.latin-5 # some Turks
|
| set config_charset=utf-8
| source ~/.mutt/aliases.utf-8 # some other aliases
|
| set config_charset=iso-8859-1
| source ~/.mutt/aliases # main aliases
|
| [...rest of muttrc and other sources in Latin-1...]
|
| reset charset # I don't want transliteration in Mutt
|
| source "~/.mutt/choose-alias-file-charset.sh|"
And the choose-alias-file-charset.sh script sets $alias_file and
$config_charset for the whole session:
| #!/bin/sh
|
| if [ $# -eq 0 ]
| then
| CHARSET="$(locale_charset 2>/dev/null)" # libcharset
| if [ -z "${CHARSET}" ]
| then
| CHARSET="$(locale charmap)"
| fi
| else
| CHARSET="$1"
| fi
|
| case "${CHARSET}" in
| ISO-8859-1|ISO-8859-15|IBM850|CP1252)
| echo "set config_charset=iso-8859-1"
| echo "set alias_file=~/.mutt/aliases"
| ;;
| ISO-8859-2|IBM852|CP1250)
| echo "set config_charset=iso-8859-2"
| echo "set alias_file=~/.mutt/aliases.latin-2"
| ;;
| ISO-8859-9|IBM857|CP1254)
| echo "set config_charset=iso-8859-9"
| echo "set alias_file=~/.mutt/aliases.latin-5"
| ;;
| *)
| echo "set config_charset=utf-8"
| echo "set alias_file=~/.mutt/aliases.utf-8"
| ;;
| esac
|
| echo "set ?alias_file ?config_charset" # tamo.multiquery.3
I make sure to never override $alias_file, and files that I source
from macros and hooks at runtime do save and restore $config_charset.
This reads and transliterates all aliases, but selects for writing the
most appropriate file and charset depending on the current locale. Pros:
number of files, and filenames are under control. Cons: Alias for a
German guy <create-alias>ed while in a Latin-2 locale will be saved to
the latin-2 file. Which is maybe good, by probably not the best place.
So manual override is possible, interactively typing:
| :source "~/.mutt/choose-alias-file-charset.sh ISO-8859-1|"
...but needs to think to do it appropriately, and needs to remember
to reset back after <create-alias> thru:
| :source "~/.mutt/choose-alias-file-charset.sh|"
Not top straightforward. But workable, for an advanced user. Those
who don't want to be bothered can use the full-UTF-8 scenario above,
which also nukes the masking of unconvertables problem.
Bye! Alain.
--
Everything about locales on Sven Mascheck's excellent site at new
location <URL:http://www.in-ulm.de/~mascheck/locale/>. The little tester
utility is at <URL:http://www.in-ulm.de/~mascheck/locale/checklocale.c>.