bug in file-name-coding-system detection

Stephen J. Turnbull stephen at xemacs.org
Thu Jan 11 10:16:41 EST 2007


Aidan Kehoe writes:

 > ‘Coding system’ is not a clear term to those unfamiliar with ISO 2022.

I didn't say it would be clear to people who don't specialize in Mule.
I did imply that it would be no less clear than the imprecise,
inaccurate phrase you used.  I believe that is true.  (NB it's not an
ISO 2022 term, it's Mule-specific.)

 > Are you suggesting we abandon any development, since we can’t test
 > our changes on platforms we don’t have access to? Wasn’t a
 > distributed form of such testing part of the point of a beta
 > status?

No.  I'm suggesting that substantial care must be taken to provide
options for users (especially testers) to work around the inevitable
breakage that happens when working on platform-dependent code, and to
be more patient about commits when it's known that the code should be
tested on platforms it hasn't been tested on.  This is especially the
case with Mule code, known to be fragile, and initialization code,
hard for the user to influence.

And no.  *Beta* testing implies that *alpha* testing is complete.  Of
course in an open source project low on manpower that will often be
more honored in the breach than the observance, but you are claiming
(and using) carte blanche.  That is totally disrespectful of the beta
testers.

 > You’re arguing with me about a design decision I didn’t make. I

Yes.  If you're going to make risky changes in that code, you should
either fix that decision or explain why it is appropriate despite all
appearances.

 > You’re not wilfully non-technical, I didn’t anticipate that
 > the idea that the better way to do things in general may cause you in
 > particular some pain, would be new to you. 

Excuse me?  You just justified not addressing the underlying problems
on the basis that you're doing nothing new, just fixing bugs in the
existing implementation.  You can't have it both ways.

 > No. The problem is not simple enough that we can provide people with an
 > interface much simpler than what we already have and have it solve most
 > people’s problems. 

What user interface?  There's `set-language-environment' (which itself
is a weak concept, poorly implemented).  The rest is just an API
sprinkled with occasional `interactive' declarations.




More information about the XEmacs-Beta mailing list