bug in file-name-coding-system detection

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

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

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.
-------------- next part --------------

 >  > 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
-------------- next part --------------
 > 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.

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

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

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

It makes sense to consider the locale as a common default, but until
we get near 100% accuracy in detection, there *must* be a flexible,
reliable way to override it, both in the UI and the API.  A coding
system alias in init.el doesn't cut it.

 > 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
-------------- next part --------------
 > 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.  Furthermore, it would also make the risk of
experimenting with hardwiring various guesses into the initialization
to existing satisfied customers minimal.
-------------- next part --------------

"I’m mystified as to why you don’t like this."

 > But all other things being equal, they’ll prefer the app that gets it right.

First, let's make the other things equal.  I'd much rather have spent that
lost time restoring mail archives or reviewing your font menu patch.