Re: CVS update: /cowiki/misc/development/tests/parser/Basic Formatting/, /cowiki/misc/development/tests/parser/

Daniel T. Gorski wrote:

>On 24 Apr 04:28, [email protected] wrote:
>
>  
>
>>Added:
>>   cowiki/misc/development/tests/parser/Basic Formatting/Bold.txt
>>   cowiki/misc/development/tests/parser/Basic Formatting/Headings.txt
>>   cowiki/misc/development/tests/parser/Basic Formatting/Paragraph.txt
>>   cowiki/misc/development/tests/parser/Basic Formatting/Underscore.txt
>>   cowiki/misc/development/tests/parser/cowiki-language.html
>>    
>>
>
>Is it possible to do three important things:
>
>a) as an unixoid operating system shell is /case sensitive/, to use
>   EITHER.UPPERCASE.FOR.FILES.AN.ADMIN.NEEDS or
>   UPPERCASE_FILES_THAT_AN_DEVELOPER_NEEDS (ever used a shell and its string
>   completition?)
>
>   or
>
>   have less important "files_written_with_lowercase"?
>  
>
An admin won't care about any of this stuff.  If they have to, we 
haven't done our job.  The idea is for us to use a GUI editor to cut and 
paste from the open file to coWiki's edit window. 

>b) avoid spaces in directory and in file names! Escaping spaces with \ is
>   the last thing an admin needs while he is working with or setting up
>   coWiki. This will also lead to problems on the long run.
>
>   and
>  
>
I'm also trying to make things easy to *read*.  I use shell completion 
all the time.  The only place I've found spaces to be dangerous is in 
java related scripts where programmers don't seem to have considered 
that spaces *are* legal in file names and paths, and so don't quote file 
names in their scripts!  :-) 

Again, these files won't be used by an admin (except possibly out of 
curiosity).  Strictly for use of someone working on the parser, like Archie.

>c) avoid the strange Windows specific extension suffixes like ".txt"? 
>   Nobody needs that (the INSTALL, README, ChangeLog etc., files do not carry
>   this), except maybe you have an extra special directory for Windows
>   users. In that case this directory should be named as such.
>  
>
If there is no extension on the file, it's not possible to associate an 
editor with it on Win32, on Gnome, or on KDE.  I see ".txt" all the time 
in Linux tarballs.  It tells me that it is a "preformatted" ascii 
document.  Is it that you are not accustomed to seeing such a thing, or 
is there an operational problem it causes you?

>A good exception in the files quoted above is "cowiki-language.html", it
>fits a "normal" naming scheme. The others don't. We should get rid of them
>and fight the roots.
>
>Is it possible to change it? I of course know, that it is possible, but ask
>you if you want to keep the software files keep an order or to want to muddle
>it?
>  
>
I'll consider what you've asked for.  My goal is clarity and ease of use 
for developers.  Many more files are needed to adequately test the 
parser.  Unfortunately one master file cannot adequately check the 
parser, so clarity in the purpose of many files will become even more 
important.  These resources are also only for parser developers-- admins 
and users won't/shouldn't care about them. 

Are these simply conventions you're unused to, or does it cause you some 
difficulty in working with them?  Please tell me if you can...  :-)

Paul