bug in file-name-coding-system detection

[Aidan Kehoe]

 Ar an t-aonú lá déag de mí Eanair, scríobh Stephen J. Turnbull: 

 > Aidan Kehoe writes:
 > 
 >  > Carefully using the XEmacs vocabulary and having non-XEmacs developers
 >  > understand what I mean can be conflicting goals. You understood what I
 >  > meant. 
 > 
 > Yes ... after about 15 minutes, having read your whole post and
 > getting halfway through drafting a reply.  Wasting my time is not a
 > good thing.
 > 
 > In this case it was completely pointless.  I can imagine situations
 > where precision and layman understanding would be conflicting goals,
 > but not here.  `file-name-coding-system' is rather clearly named, and
 > a useful gloss is available via C-h v.

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

 >  > I don’t know. It’s your system; I’ve no idea if it does the
 >  > sensible thing and presents a normalised UTF-8 api for those cases.
 > 
 > *sigh* It doesn't matter.  When you have access to about 1% of the
 > variant systems that run your code,

Like everyone. Do you remember how many systems XEmacs runs on? 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? 

 > the file name coding system should be a *variable* that can be easily
 > bound or buffer-local for quick fixes and special uses, not an alias for
 > a constant coding system.

You’re arguing with me about a design decision I didn’t make. If there’s a
design decision in XEmacs that you don’t like and you have a better approach
that solves the same problems, implement it. Don’t give other people hassle
for acknowledging that those decisions were made. 

 > There is such a variable, but at the very least the existence of an
 > aliasable coding system confuses things, and maybe reduces
 > reliability.  Please fix that, and give us a UI, before you go
 > hardwiring things.
 > 
 >  >  > We now have *three* users on *three* different systems who were hosed
 >  >  > by this patch. 
 >  > 
 >  > Who? You, okay. But Volker Zell and Wulf Krüger? How is having a German
 >  > menubar in a German locale ‘hosed?’ M
 > 
 > Both were surprised, and insisted on learning how to get rid of it.
 > "Hosed" is an exaggeration, but the direction is right.
 > 
 > Furthermore, Wulf's menubar is *not* in a German locale;
 > LC_MESSAGES=en.  "Forgetting" that fact is exactly the kind of
 > carelessness that causes me to oppose your patches.

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

 >  > Bullshit. The intuitive thing is for XEmacs to pay attention to the
 >  > locale
 > 
 > First get XEmacs to pay *proper* attention to the locale.  It
 > currently does so in a very buggy way, as you point out yourself.

I don’t have strong feelings about it either way; I can see the logic behind
it, and it is clear that it contradicts POSIX. Either way, it’s a design
decision I didn’t make. 

 >  > and use that information. If the user has a particularly riced-out
 >  > environment that doesn’t conform to expectations, then that user
 >  > can modify the file-name and native coding system aliases by hand.
 > 
 > Sure, they can.  But the problem is not that the environments are
 > riced-out; it's that you limit your expectations to what you deal
 > with.  You put a different spin on it, but that's the excuse you use
 > regularly for committing buggy patches.  "I don't have that system, so
 > I couldn't test it."

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?
 
 >  > On Standard Average Unix, it _is_ the file name encoding. I’m
 >  > mystified as to why you don’t like this.
 > 
 > Because your obeisance to this fictitious Standard Average Unix cost
 > me hours.  I'm mystified as to why you think I should like that.

I’ve had epic flame wars with Peter T. Daniels in sci.lang for using UTF-8
in my posts. In sci.lang. Where the necessity of using the IPA and non-Roman
scripts is daily. Now, there are workarounds to the absence of phonetic
symbols in ASCII, but by far the best solution is to use UTF-8 there. He’s
shut up about it since he abandoned Netscape 3 for Google Groups and no
longer sees the problem.

Peter’s an expert on writing systems and a Semiticist, and wilfully
non-technical. 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. 

 >  > Users don’t care that much, in Europe. That we don’t respect the
 >  > environment just makes us look bad. People still get work done when
 >  > they see their name as Krüger or René, and the investment of time
 >  > to get it working right--when getting it working right is often not
 >  > possible--is not economic.
 > 
 > In other words, providing them a simple flexible way to customize it
 > would give them 90% of what they want, at no risk to existing
 > satisfied customers.  

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. 

-- 
When I was in the scouts, the leader told me to pitch a tent. I couldn't
find any pitch, so I used creosote.