Re: Stop building 21.5 nomule

Stephen> The problem is that having coding cookies in the Stephen> xemacs-packages hierarchy implies calling a Mule API in a Stephen> no-Mule XEmacs. The only way to fix that is to remove Stephen> support for no-Mule builds. Mats> What about an error message when a non-mule XEmacs finds a Mats> coding cookie then? XEmacs eating all CPU endlessly or Mats> crashing due to SEGV doesn't seem that user friendly. It needs to be an error, though---a warning isn't good enough because you'll crash anyway. So no matter how you look at it, the cookies have to come out of packages in xemacs-packages. It should be possible to allow 8-bit coding systems. If something more than 8-bit clean processing is needed (eg, correct syntax and case tables), you will lose, but that could be demoted to a warning by default. We should be able to handle ISO-8859-1 correctly, and all of the Latin ISO-8859-X family should be safe and "almost correct". For the non-Latin alphabets (Cyrillic, Greek, Arabic, and Hebrew), it should be safe but I doubt correct. Mats> OK. So either the offending packages need to go strictly Mats> ISO-8859-1 or move out to mule-packages. Right? Yes. I don't like it, but something is necessary, and that is the best policy we were able to come up with. However, nobody's thought about it for a long time, so I'm open to suggestions. (They need to be gradual and backward-compatible, though, for 21.4.) I'd like to work on this, but I'm currently over-promised. Maybe Aidan or Ben will, though. I should mention that Ben talked about putting at least a UTF-8 codec into 21.4, which would theoretically allow us to remove the distinction between xemacs-packages and mule-packages for all future versions of XEmacs. I don't recall a transition strategy though. Doing the coding system wouldn't be hard, I think. The hard part is arranging that "old" non-mule XEmacsen get no-mule packages. I think this would probably involve some duplication across the mule/xemacs hierarchies. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.