Yes. UTF-8 and NFD, I would say.
As much as I like NFD (well, I'd like it even better if
Korean NFD hadn't been made permanenlty broken between Unicode 2.x and
3.0), I don't think people will ever agree on NFD part.
How very true... some other people will say NFC, some will say neither,
some wi
On Thu, 25 Dec 2003, Jarkko Hietaniemi wrote:
> >> Whoa! It's the other way round here. Nick is using a locale that
> >> suits him for other reasons (e.g. getting time and data formats in
> >> proper British ways), but why should he be constrained not to use for his
> >> filenames whatever he
On Thu, 25 Dec 2003, Jarkko Hietaniemi wrote:
> >> What I wish is that the whole current locale system would curl up and
> >> die.
> >
> > As you'd agree, it's only 'encoding' part that has to die.
>
> Oh no, there are plenty of parts in it that I wish would die :-)
Wishing it to die is diffe
What I wish is that the whole current locale system would curl up and
die.
As you'd agree, it's only 'encoding' part that has to die.
Oh no, there are plenty of parts in it that I wish would die :-)
(though the coupling of encoding is a major booboo). Other parts
include (some of which Nick alre
Whoa! It's the other way round here. Nick is using a locale that
suits
him for other reasons (e.g. getting time and data formats in proper
British ways), but why should he be constrained not to use for his
filenames whatever he wants?
Then, he should switch to en_GB.UTF-8.
That will work if t
On Thu, 25 Dec 2003, Jungshik Shin wrote:
> locale definition. The fact that it is on Unix is just an artifact of
> Unix file system and we want to leave it behind us if possible. Of course,
Of course, it's rather a whole lot of different
things that bind locale and encoding on Unix, from which
On Thu, 25 Dec 2003, Jarkko Hietaniemi wrote:
> What I wish is that the whole current locale system would curl up and
> die.
As you'd agree, it's only 'encoding' part that has to die. Everybody
should switch to UTF-8 on Unix and end-users should never worry about
'encoding'. In an ideal world,
On Thu, 25 Dec 2003, Jarkko Hietaniemi wrote:
> > locale. Why does Perl have to be held responsible for your intentional
> > act that is bound to break things?
>
> Whoa! It's the other way round here. Nick is using a locale that suits
> him for other reasons (e.g. getting time and data formats
Let's not 'fix' it (not carve it on a stone), but offer a few
well-thought-out options. For instance, Perl may offer (not that these
are particularly well-thought-out) 'just treat this as a sequence of
octets', 'locale', and 'unicode'. 'locale' on Unix means multibyte
encoding returned by nl_la
Anyway, introducing a new env. variable is not a solution to
the mess. By doing so, you just add another problem because a new
variable is only meaningful to Perl at least at the beginning.
My proposal of LC_FILENAME was not that serious.
What I wish is that the whole current locale system would
On Tue, 23 Dec 2003, Nick Ing-Simmons wrote:
> Ed Batutis <[EMAIL PROTECTED]> writes:
> >> I don't think we understand common practice (or that such practices
> >> are even established yet) well enough to specify that yet.
Common practice is that file names on 'local disks' are assumed to be
in
11 matches
Mail list logo
