no, no, no, I still strongly dislike the introduction of a new end-of-header token.
the existing defined semantics are enough to write some simple code to detect the end of the header: it is simply there where the first non-comment line comes, ie that is a line which is of type 1, 2, 3, 4 or 5, or a 0 BFC or 0 !TEXMAP or 0 !COLOUR
let me also question for what _purpose_ such a token would be useful:
1. what is so bad about LDFind if it indexes the whole file instead of just the first bunch of lines? don't you want to find _all_ occurrences of a word in a file?
2. if we're talking about using a revision control system for our parts like git, hg or Perforce, which I strongly suggest, then the _whole_ file will go into it, not just the header. That way our files would really get a lifecycle history of their full contents. We're talking about simple
fulltext files here still, which can easily be stored in tools like that, allowing easy diffing etc like for programming language source code files.
And yes, agreeing to the said things above: using anything that starts with 0 // must not be done under all circumstances,
because it breaks the rule that everything after 0 // is a totally free formatted,
no machine-readable-semantics-carrying human-readable comment.
the only degree of freedom we have here is choosing something that starts with 0 !...
the existing defined semantics are enough to write some simple code to detect the end of the header: it is simply there where the first non-comment line comes, ie that is a line which is of type 1, 2, 3, 4 or 5, or a 0 BFC or 0 !TEXMAP or 0 !COLOUR
let me also question for what _purpose_ such a token would be useful:
1. what is so bad about LDFind if it indexes the whole file instead of just the first bunch of lines? don't you want to find _all_ occurrences of a word in a file?
2. if we're talking about using a revision control system for our parts like git, hg or Perforce, which I strongly suggest, then the _whole_ file will go into it, not just the header. That way our files would really get a lifecycle history of their full contents. We're talking about simple
fulltext files here still, which can easily be stored in tools like that, allowing easy diffing etc like for programming language source code files.
And yes, agreeing to the said things above: using anything that starts with 0 // must not be done under all circumstances,
because it breaks the rule that everything after 0 // is a totally free formatted,
no machine-readable-semantics-carrying human-readable comment.
the only degree of freedom we have here is choosing something that starts with 0 !...