1) A way to specify entries whose content is entirely or partially escaped
Usually, the overstep AGC can be used to escape characters within an entry which would usually be understood (and therefore processed) by the parser as AGCs or other reserved characters. However, in scripts with a large amount of pre-formatted text containing a number of reserved characters, and little need for AGC functionality (particularly when using Regnus to generate (X)HTML, for example), this can be time-consuming and lead to convoluted code. Therefore, this suggestion is for a method of notating that a particular entry should not be parsed.
The proposed solution would be to allow the existing overstep AGC to work in the same manner as the capitalisation AGC, and apply to spans to paranthesised text. For example:
Code: Select all
ENTRY This entry is parsed, but *(<em>these instances of markup</em>) are not, as they are within an escaped span.
ENTRY *(This entire entry is escaped, thus <strong>this markup</strong> does not need to be separately escaped.)
ENTRY This reference will return unparsed text: *(##AnotherGroup;)
2) A "DRAFT" qualifier adding "include" functionality
A suggestion originally mooted for the 5.4 specification is some form of "include" functionality, which would work in a similar way to other programming and scripting languages, in that it would cause an external script to be included in the current script and treated as a single script.
It is already possible, of course, to use the $ RTC to reference content in external scripts, and this already allows for all of the functionality which an include function would provide. However, the subtle difference is that using a reference creates and additional recursion and returns fully processed parsed content from an external script, as the two individual scripts are effectively "blind" to each other's contents. An include function would actually cause the external script to be loaded into memory as if it was part of the current script, meaning that its groups would be accessible in all the usual ways, without having to create handler labels in the second script to grant access to its content.
The proposed syntax for this function would be:
Code: Select all
This would be relatively easy to implement, but might not be desirable as it essentially duplicates (though in a simplified fashion) existing functionality, and also, would potentially cause issues as the included script would not necessarily be complete and valid, and would cause duplicate metadata qualifiers if it were to be a complete valid script. External scripts in this case would be more likely script "fragments" containing only groups of entries with no labels, for instance, so it may be necessary for simplicity of debugging to include new metadata and specify that a particular file is deliberately a fragment rather than a complete script.
Another issue that would be important to consider would be how this new qualifier would behave depending on where placed within a script. One implementation would be that, no matter where placed, the qualifier would append the given fragment to the end of the script, meaning that all groups within the fragment would need to be complete. Another implementation would be to allow fragment files to be inserted directly into certain points within a script, allowing (for example) additional entries to be inserted directly into groups. This would be powerful, but would also be more difficult to implement. A third option would be to allow selective importing of data from an external script. For example, only the external script's groups might be imported (or even specific groups?), with all labels stripped, allowing lists of data to be imported from complete external scripts and thus also solving the issue of the functionality requiring the creation of "fragment" scripts as discussed above.
Another important consideration regarding this proposed functionality is that it would almost certainly add additional loading time to scripts which don't even use drafting, and would add a level of complexity to the language which might be undesirable given that it adds a minor convenience for some authors, but no new functionality.