Re: Fucking Mulål

>>>>> "Hrvoje" == Hrvoje Niksic <[email protected]> writes:

    Hrvoje> I'm having a hard time figuring out a scenario where it
    Hrvoje> could go wrong and produce this kind of result.

Me too.  I'm pretty sure that somehow Mule is deciding to save in
Latin-1/binary.  But why I am unable to guess.

    Hrvoje> Note that my default coding system is Latin 2 *anyway*, so
    Hrvoje> failure to guess anything would still result correct
    Hrvoje> behavior.

Unfortunately, as I've discovered as I delve deeper into how Mule
actually does what it does[1], "that turns out not to be the case".
Mule never fails to guess, it just sometimes guesses wrong.  This is
one of those bugs that will get solved by ripping out and rewriting
the whole detection subsystem (which is one thing Ben is doing), as
trying to patch it in place seems hopeless; the whole concept is
fucked.

    >> although you're one of the few people I'd trust to get it right
    >> (I hate coding cookies...).

    Hrvoje> I've never quite figured out what your problem was with
    Hrvoje> the coding cookies,

Because they are very easy to forget to change, and I deal with the
bug reports.  People are often convinced that XEmacs should get it
right even though the cookie is wrong!

    Hrvoje> Good point.  I'll try using the unity thing.

Shoulda said "it gives some useful information" in the first place.
Because that's the main reason why you should use it (rather than go
back to no-mule, which is pretty easy and no-maintenance for you
personally).

    >> autosave handling of coding systems has always been and
    >> probably still is a little bit broken.  Did you do any
    >> recover-files?

    Hrvoje> As a matter of fact, I did.  And I was surprised to find
    Hrvoje> it working perfectly.  (But that might have been due to my
    Hrvoje> default coding system.)  Maybe it is broken in a more
    Hrvoje> subtle way, which corrupts the file when it's saved much
    Hrvoje> later?

Well, somewhere in 21.2 Ben changed things so that _all_ autosave
files are escape-quoted.  I'm pretty sure that escape-quoted is
actually an ISO 2022 coding system, slightly tweaked.  The downside
possiblities are endless....  We changed it back in 21.4.6 to use the
buffer's normal coding system later, because there were bugs in
escape-quoted that hosed all the ISO-2022 coding systems.  Ben claims
to have fixed the bugs, but the whole strategy is wrong.

I don't know if there is a right one.  There are three strategies I
can think of:

    o autosave is buffer-image
    o autosave is what save-buffer would do
    o autosave is text image of buffer (ie, in a universal coding
      system, ESC/Quot is supposed to be one)

All have problems.  Buffer image is not readable by anything but
XEmacs, and if it should happen to be corrupted, XEmacs can crash.
You also need to assign the coding system of the restored buffer
somehow.  save-buffer is quite capable of corrupting the file, as you
know.  A corrupted autosave is worse than no autosave at all.  And the
UCS/text-image strategy isn't right because (1) not all files are
character text, and (2) UTF-8 is corruption to a user who wants
Latin-2.  And you have the same problem of assigning the coding system
to the restored buffer.

    Hrvoje> As I said, the code is not doing anyhting Mule-specific.
    Hrvoje> It is blissfully unaware of Mule, except for the bit with
    Hrvoje> determining the coding system and the bit I added with
    Hrvoje> composing mail buffers.

My, aren't you trusting.  Remember, Mule is brought to you by the same
people who brought you APEL and TM.  Your code may be fine, but how do
you know that Mule isn't changing semantics behind your back?  In
fact, you can be pretty damn confident it's changing semantics behind
your back.

I know this isn't going to help to sell you on Mule, but ... really,
in this kind of circumstance you need to treat Mule like you would any
hostile alien intelligence.

    Hrvoje> I still claim that Mule is pure overengineering for
    Hrvoje> Croatian.

    >> Well, of course it is.  But it's not over-engineering for a
    >> Croatian working in Germany

    Hrvoje> Wanna bet?  All the umlauts are present in Latin 2.

Sure.  How about €10?

I know the standards.  ;-)

    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.

    Hrvoje> What is that supposed to mean?

Let me rephrase that: I doubt that anybody who cares enough to work on
XEmacs internationalization will sympathize much.  If we want it to
"just work" when you feed it a language you personally haven't used
before, we need something like Mule.  Yes, we could fix things up just
for Latin-2 and just for Cyrillic and just for Greek, but that's
neither fun nor likely to happen any quicker than fixing Mule.

The people who matter (eg me and Ben) are willing to put a _lot_ of
effort into fixing Mule, but very little into Croatian solutions to
the Croatian problem.  And your problems are Mule-wide, they affect
everybody (they're much less frequent for me, and the benefits of
using Mule far outweigh them, but I've now learned to recognize them
when they bite).  They will get fixed.

I suspect that what Ben fails to understand is mostly why you rant
instead of fixing the bugs.[2]  At the moment, bugs in the abstract is
all they are to Ben---they don't hinder him in work or play.  All his
languages are Latin-1, you know.


Footnotes: 
[1]  Note how much effort I go to to avoid the word "works"!

[2]  I mean that literally, I'm not criticizing you.  I wish you
_would_ fix the bugs, but it's an awful lot of effort for not that
much gain from your perspective.

-- 
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