I’ve just updated aTbRef9, this time using v9 (as-yet private beta testing a fix to the earlier export), i.e. not using v8 to for export. I’ve fixed a few more reported/unreported issues and omissions.
I’ve added further polish to the change reports. Unlike past baselines, items changed in this version are flagged as such, though not expressly mentioned, whereas changes for v9.0.1 or v9.1.0 or whatever next version) will be annotated in the text of notes affected. This strikes a balance between lots of “in version N.x.y” scattered across text and confusing to new users whilst giving existing users—or those upgrading after a pause—some indication of where familiar features may have changed or grown.
As a result v9.0. is listed as the first change log, although it is actually the baseline version aTbRef9. I’ve also added into the v9.0.0 change log note the apps’ Release Notes listing on minor/back-of-house changes (much bigger here as a major version release) and—where pertinent—linked the notes to the main text. The change log also has a link to Eastgate’s v9-specific release page. All this is by way of helping users find out about changes and fixes.
Similarly, for Attribute and Action listings, I’ve changed the pages so new/changed items in the baseline (v9.0.0) release are clearer. For example, $CodeFont, though now in the baseline is shown as being added in v9.0.0—as opposed to existing before v9, which is what an entry of “Baseline” now implies. An example of a change in v9.0.0 can be seen in collect_if(). Here, the term “Baseline” applies correctly but the codet also changed in v9.0.0 (re honouring $Searchable settings) and this is reflected on the aTbRef9 notes.
In part all these changes build off some re-factoring of the TBX to store the current version—plus its build number, release date, etc.—in one place so that baseline related functions can auto-update more easily (there are more such references than you might suppose).
Now I’m using v9 to export v9 again, and not juggling source TBXs, updates should be quicker & easier to implement so please keep error reports coming.
One item still on the jotter is an explanation of how zero-config markdown preview works in a doc that may also have export templates (my suspicion—many Markdown users). Suggested wording welcome. The feature works fine, it’s just hard to describe simply.