Re: bug in file-name-coding-system detection

Thursday, 11 January 2007

 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.

_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998