|
From: Bernard B. <be...@lp...> - 2007-01-05 00:01:35
|
>Support for different high-ASCII encodings, 8-bit Unicode, the HTML
>"encoding" should all be considered. Also, it might be convenient to have =
a
>low-ASCII-only syntax for polymetric expressions. (I know that period
>notation allows '.' instead of '*', right?
Right.
>What about undetermined rests?)
The alternative low-ascii is "_rest".
I promoted the use of "_rest" rather than "=8A" (HTML code "…")=
because the latter could be confused with three periods. For the period=
notation I found it nice to keep '*' ("•") as an option because it is=
more visible in the text. These are the only high-ASCII signed used in BP2 =
syntax.
If files are systematically stored as HTML, which is already programmed as=
an option in the current version, we won't need to bother about=
cross-platform compatibility.
I remember filtering out high-ASCII in the names of variables and terminal=
alphabet. Accepting high-ASCII (from European languages) may look more=
flexible but I am afraid of the mess-up between the different versions of=
high-ASCII: "latin", "Central-Europe" etc. If we start broadening the=
alphabet options (in a later version) then let us take Unicode and accept=
"exotic" alphabets as well.
> > However, if I append ".doc" after "-gr.dhati" which was created by BP2, =
the
>> file "-gr.dhati.doc" is still displayed with its old icon, and double-cli=
cking
>> it still launches BP2 via Classic. Therefore, if the file has a signature=
and
>> type, these remain dominant over the information provided by its name.
>
>I have not tried this, I hope that it is always true ...
I tried it on MacOS 10.3.9.
>The mandatory suffixes is the recommended approach by Apple. I personally
>believe that this is a very wrong choice. Users should be able to name a
>file whatever they want. If the suffixes were ALWAYS hidden and never
>required the user to know about them, then they would function like OS 9
>file types, but they do not. The fact that the OS X Finder puts up a
>warning dialog when changing a file suffix is extremely irritating and
>confusing to the user in my opinion.
I agree with this, but we need to compromise and take into account Windows=
versions at a later stage.
>All true, but adding a simple "comment" at the beginning of the file to
>identify it as a grammar, homomorphism, etc. file may be the only way to
>guarantee being able to identify the files cross-platform. I see that
>recent versions of BP2 already do this for most of its file types:
>
>// Grammar file saved as '-gr.dhati'. Date: Sam 21 Juin 1997 -- 21:39
>// Alphabet file saved as '-ho.tryCsound'. Date: Sat, Jan 11, 1997 -- 17d24
>
>We could definitely look for these comments to confirm a file's type but no=
t
>make them mandatory.
You are right. I had forgotten that I added a single-line header in a=
comment. This is quite consistent and it can be used for file type=
recognition as a priority. If this header is missing (which may happen if=
the file was created with an external editor) the program should look at=
the prefix. If no prefix is present, then it will look for a suffix. If=
case it finds the header it will indeed correct the prefix (if=
inconsistent) and the suffix (if the suffix option is checked).
>I think a global preference for prefixes, suffixes, (and prehaps neither) i=
s
>a very good idea.
Neither is also a suitable option since the information will be stored in=
the header.
>I am against the idea of the save dialog forcing any
>particular behavior though.
Me too.
>I think BP3 could be made very "smart" about all of this and look at the
>traditional Mac filetype codes, the prefix, the suffix, and the contents of
>the files (in that order, I think) to determine file type. Mac filetype
>codes can be relied on without question when present unless the type is
>'TEXT'. The contents of a file can be used to confirm whether a prefix or
>suffix is correct. If any of those three do not match, perhaps the user ca=
n
>be asked for the correct type.
It is possible to ask if there is a preview of the file content, which is a=
bit more complicated as the detection of the file type happens at the time=
of opening it. It could be programmed later if we feel it it necessary.
I remember having programmed robust procedures to maintain file header lines=
and avoid thir duplication, among other problems.
>I also wonder whether we might be better off using "structured" text data
>for some of the files such as settings and Csound instruments which are not
>currently very editable by the user anyways. XML is becoming quite popular
>for this purpose and has the same benefits as HTML as well as library
>support built-in to OS X and probably other operating systems as well.
I fully agree. I had planned to do so. It will make it much easier to=
handle settings file consistency across versions of the program. In the=
current version I have put lots of "if" statements when reading a settings=
file so that it assigns the proper meanings to the values that are found in=
the file. This would be much easier to manage if it were in XML. But we=
may do it after the MacOS X port and allow the program to read "old" format=
s.
I think we've sorted out this topic entirely. Options left pending may be=
further considered in the next version.
Bernard Bel
|
