Eric Blake wrote:
Rather than complaining, write a patch to prove your point. Patches speak
much louder than rants on open source projects. But I won't be the one
writing the patch.
----
I already supplied code in the first email. It's a matter of
using those constants instead of the ones being used.
Corinna Vinschen wrote:
According to Linda Walsh on 11/28/2009 3:24 AM:
Any other standards group I know of is going UTF-8. All of the
linux distributions I know are going UTF-8. I'd like to see Cygwin
go that way too.
I don't understand this one. What on earth are you think we're doing?
Do you really understand the sense of the mapping?
---
You are trying to allow use of the commonly usable
'7 banned chars' (under DOS) that are occasionally used
on Unix. No? The UTF-8 is referring to the fact
that the substitute chars I'm referring to would be
viewable on platforms using UTF-8 -- as the unicode
values in UTF-16 are directly convertible to UTF-8
platforms (which such wouldn't be the case to platforms
using not Unicode-based platforms).
But that mapping doesn't make sense. Instead of mapping valid, but
forbidden characters into a range which doesn't contain valid
characters, the valid characters are then mapped onto other valid
characters. How are you going to ever map them back? When is a
FULLWIDTH QUOTATION MARK actually a QUOTATION MARK and not really a
FULLWIDTH QUOTATION MARK? You're covering perfectly valid characters
and make them unusable. Besides, we have not only to map the few
characters you're talking about, the U+f0XX range is also used to
map invalid UTF-8 chars.
----
I'm aware that this would reserve the 'display forms'
of those chars and map them them to their real forms when
interpreted within cygwin. I don't see this to be a problem.
There are no applications that currently use those
values because cygwin 1.5 didn't support either the real
ascii values OR the unicode values. It's a matter of
seeing those file names, produced by 1.7 as semi valid
values when viewed in explorer and when they are viewed
on linux servers. _I_ use those values in filesnames,
and know of no compatibility problems having them
treated as 'real' ascii characters under cygwin --
since I am just using them for 'display' purposes
in file names like like "Music:the group:title 1/3".
In linux and windows, I'm using them as display forms.
I put quotes around the filesnames so whether they are converted
to real ascii forms under cygwin or stored as visual display
forms is of no consequence.
I don't see a problem. And the patch is just
changing the hex values used to the ones I supplied in
my original posting.
Am I indicating an understanding of the problem
and implications? Do you feel it's really a problem given
how they are commonly used and how there would be no
conflicting applications?
linda
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
