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