Ar an dara lá is fiche de mí na Samhain, scríobh Uwe Brauer: I agree, thank you Jeff! Ah, that’s a shame. We have the try-alternate-layouts-for-commands variable, which says to attempt to work out what a given key sequence would have been on a Latin keyboard, and to call the corresponding command, if lookup-key would otherwise have failed. But I don’t have the access to GTK to port that over from X11 at the moment. Definitely UTF-8! -- ‘Liston operated so fast that he once accidentally amputated an assistant’s fingers along with a patient’s leg, […] The patient and the assistant both died of sepsis, and a spectator reportedly died of shock, resulting in the only known procedure with a 300% mortality.’ (Atul Gawande, NEJM, 2012) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Right, but we are anyhow talking about 21.5.X since jeffs gtk branch is a 21.5 branch, right? So hebrew for 21.4 seems useless? Yes I am talking about 24. And no the their hebrew file, in their quail package is not UTF8 encoded, instead it has the following header. ;; hebrew.el --- Quail package for inputting Hebrew characters ;; -*-coding: iso-2022-7bit;-*- So Aidan says yes to UTF8 you seem to say no. What shall I do? Uwe Brauer _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Stephen J. Turnbull writes: As I wrote to Aidan, I won't put UTF-8 into the packages at this point in time, but I won't veto it if he wants to do it. Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Uwe Brauer writes: This isn't ISO-2022-7bit, this is 8bit (UTF-8, in fact) with the DOCS control sequence. Effectively it says "ISO 2022 can't handle this, so we'll talk UTF-8 for a while". As far as I know, that has not been even close to true for a while. Most of the more recent additions to Unicode do not have ISO- registered coded character sets, so you need the above "include UTF-8 in the ISO 2022 stream" workaround. If so, that's the Thai government's fault, not that of Unicode. Unicode is basically a consortium of national standards bodies. It does not decide which individual characters belong in Unicode, only whether a proposed set is actually a new character set, and where to put those characters not already in Unicode. *Much* simpler and more portable. Unicode is a *single* extensible character set. It is easy to make a (possibly ugly, but probably readable) font for it, and once that is done, *any* Unicode implementation can display it. (Doing a good job for some scripts like Arabic or Thai is quite hard, but that has nothing to do with Unicode vs. ISO 2022.) If you have a character set that you want to implement that isn't in Unicode already, make a font and use some of the several hundred thousand character codes reserved for "private use". Very easy! ISO 2022, on the other hand, is a framework for *switching* character sets. In order to implement ISO 2022 you need to know the code that designates each character set, and you have to have a font for the specific set of codes (which may differ for the same character in different sets). XEmacs faces an even bigger problem, which is that the set of codes for designating character sets internally is *very* limited (only a few dozen), and they are all already in use. GNU chose to use private codes for some standard sets, so they had ten more, but even so they were about to run out when they switched to Unicode inside. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta