Re: Fucking Mulål
"Stephen J. Turnbull" <[email protected]> 25 Apr 2002 19:53:29 +0900
| Newsgroups | gmane.emacs.xemacs.mule |
|---|---|
| Organization | The XEmacs Project |
| Message-ID | <[email protected]> |
>>>>> "Hrvoje" == Hrvoje Niksic <[email protected]> writes: Hrvoje> You mean po-mode.el? Right. Sorry, Debian (I think) distributes it as el-gettext.deb or something like that. Hrvoje> The only Mule thing it does is a tiny hack that allows it Hrvoje> to set the coding system based on the PO file's Hrvoje> Content-Type. Sounds like it's somehow getting that wrong, although you're one of the few people I'd trust to get it right (I hate coding cookies...). Maybe related to the other bug you mention. Hrvoje> It would be hard to make it a formal test because this Hrvoje> thing happens so rarely. If I could pinpoint when it Hrvoje> happens, I could probably get to the where and why. True, but if it stops happening, I can take credit. Also, if something weird happens to change Mule's idea of the right coding system, there's a good chance latin-unity will notice. Eg, if you save, and work, and save, and work, and save, and ... oops, a buffer popped up saying "your default coding system iso-8859-15 can't save this buffer", that might help localize things a bit. Off hand possibilities: write-region-internal is currently broken in all XEmacs versions AFAIK: it doesn't actually do anything with the explicit coding-system argument. I just discovered this recently. autosave handling of coding systems has always been and probably still is a little bit broken. Did you do any recover-files? Hrvoje> It's an old version of `po-mode', hacked for my own use. Hrvoje> But as I said, that code is largely unaware of Mule (as it Hrvoje> should be), so I don't think upgrading `po-mode' will Hrvoje> help. Well, given the way that Mule developers have historically paid attention to their own defined APIs (== not), it's hard to say what's happening without looking at the code. Also the way Mule tends to do internal communication via dynamic binding rather than defined APIs anyway. Hrvoje> I still claim that Mule is pure overengineering for Croatian. Well, of course it is. But it's not over-engineering for a Croatian working in Germany who needs to deal with texts explicitly labelled ISO 8859/1, ISO 8859/2, ISO 8859/15, or UTF-8, etc. Hrvoje> When Ben wrote about "Hrvoje's weird font mapping tricks," Hrvoje> I started to compose a long response, but gave up because Hrvoje> I just knew he wouldn't understand. I really don't think anybody will. Really the right solution is to fix, rebuild, and/or replace Mule facilities. Make them simpler and more self-contained, and especially make them do what you say. I understand why you want 8-bit buffers with no "coding systems" and just a few helper add-ons for input and stuff, but it's just not sufficient for a robust application in the modern environment. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py