>> The question is whether it can be useful for a Unix shell session.
JS> I'm not sure I understand your point...
Luit is designed to provide support for legacy encodings to UTF-8
terminal emulators. It is not a general-purpose encoding converter.
Viewing mails or web pages is a different matter, because every mailer
or web browser worth its weight in peanuts should be able to do
conversion of e-mails internally. The issue is whether you know of a
scenario in which terminal-based applications may want to use the
encoding for speaking with the terminal..
>> (On the other hand, I certainly have no ideological objection to
>> including Microsoft encodings. Luit is by design the place to put all
>> the trash that we want to keep outside of XTerm.)
JS> What I'm afraid of is that adding more support for legacy encodings
JS> will drag out the transition to UTF-8 forever.
My personal plan is to prevent people from implementing legacy charset
support in terminal emulators. I think that the best way to do that
is to provide as much support as possible in luit, so that people
don't feel the need to implement it elsewhere. This will also allow
writers of terminal emulators to concentrate on providing good UTF-8
support rather than spending their time implementing legacy encodings.
Thus, I feel that adding support to luit will facilitate rahter than
hamper transition to Unicode.
JS> An off-topic issue: did you get my new patch to ksc5601.1987-0.enc?
JS> I'm just wondering because my mail system had a temporary outage
JS> about the time I sent you that patch.
Don't send patches to me (unless you feel they may break my code).
Send them to the submission address.
Juliusz
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
