At 06:49 AM 3/13/2002 -0600, Bryn Wolfe wrote: >I think we're getting a little too much of the old school of thought here.
Hmm... the "old school of thought" was that documentation and references should be clear and unambiguous. No, we don't have enough of the old school, not too much. > Not allowing lowercase is just too primative. If you're going to take > away the spaces, give me my lowercase. That's even worse than spaces. Some file systems (such as DOS, up through NTFS, if I am correct) treat lower case and upper case as equivalent. Some don't (i.e., unix et al). A system that should be compatible with both -- and I think that desireable -- will necessarily avoid lower case, or will treat lower case the same as upper case. The former is better than the latter, in my opinion. Removing the length restriction was sufficient to provide for enough fully descriptive names that the additional space of lower case is completely unnecessary. Note that it is difficult to read lower and upper case as being distinct from one another. If I communicate the name of a part verbally it is convoluted for me to include case information. It is not a natural representation of the language. Some languages don't have this distinction, Arabic for one. Latin for another, I think. > To avoid the filename-in-quotations-because-of-spaces problem I rarely > use spaces and instead use lowercase with the first letter of each word > capitalized. I'm and advocate of being succinct, but clear. Losing > lowercase is a detriment in my opinion. I want to allow every character > that is possible for a file name, excluding spaces. In windows, this > excludes the following characters. > >\ / : * ? " < > | I agree. Quotation marks should not be used; if they are allowed, many user-written utilities will need to become more complex and bug-prone. >I believe that is the same restriction for Unix-related OSes and Solaris. >It works for them, why not for us? And this lower case oh (o) vs zero (0) >and lowercase ell (l) vs one (1) is simply a font problem. You might as >well not allow the upper case letter oh (O) either because it looks like a >zero (0) as well. Just fix the font, no big deal. That is, in fact, the only solution to this one, because we need the letter O and we also need the number 0. I favor the slash for zero, in spite of what was on the reference cited by another. But any font device that makes the distinction unambiguous is fine with me. As to the problems with the Nordic languages, well, I don't think we can solve everything. You should see what is involved in trying to write Arabic in ASCII. It is a total mess.... >I believe we can think outside the teletype restrictions of 30 years ago. >If not, maybe it's time to retire ;-) Ahem. The issue is clarity, and what could easily be taken as a personal insult will not help to resolve it. Allowing lower case letters can improve clarity, mostly by being a signal for word gaps. But underscore fills that need nicely, without the added complications introduced by lower case. As long as the Windows file system treats upper and lower case as the same, I would be very much against preserving lower-upper case distinctions in file names. Allowing them to be entered and kept can cause confusion, i.e., one does not automatically know if case is important or if it is not. The program should handle that for the user, i.e., if the user enters lower case, it should be represented as upper case immediately. If a user enters a space, it should immediately become an underscore. Abdulrahman Lomax Easthampton, Massachusetts USA * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://email@example.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *