On Wed, 4 Dec 2002, seer26 wrote:
> > Filenames are _names_. They are names for _human_ use; computers would
> > be just as happy passing about inode numbers. Humans don't like
> > dealing with strings of bytes. They like dealing with strings of
>
> I think we both agree that different file names should look different.
I guess there's a difference of opinions on what makes filenames
different between you and David.
> The question is not whether normalization should be done, but where. My
> argument was that it should not be done inside the kernel, filesystem,
> compiler, linker, etc. But instead it should be dealt with at the Input
> Method, and user interface level.
As for linker, you're assuming that you always
work _alone_ with a single compiler, a signle programming language and
a single editor.
> (Normalized strings would always be generated by user input, and
> non-normal strings would be displayed as escape sequences.)
What's your definition of normalized string and non-normalized
string? If you're talking about overlong/invalid UTF-8 sequence(or
invalid in the present encoding), what you said makes sense. Otherwise,
it doesn't. Why would they( strings in one NF and strings in other NF)
be treated differently by *UI*? They're equally valid as repersentations
of strings of _characters_. Your view that they have to be treated
differently is not consistent with your view that UI/input method
are places where normalization should occur. If UI does that, your
'non-normalized' string should be treated by UI the same way as your
'normalized' string is. That's what 'normalization' is for. It's not a
one-way street(from user input to system) but a two-way street.
For sure, some advanced users may want to examine 'binary contents'
of filenames. That should be provided as optional features of UI.
Jungshik
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
