sentinel lines

Sentinel lines

Embedded lines for static analysis, many times as *nix style octothorpe comment lines.

• Also like git-versioning, see GV:doc/manual.rst. Example::

  var my_version = 'foo' # App-Id

  Id: App-Id/App-Version

• Overlaps with literal domain (Markdown, reStructuredText, MediaWiki etc.) and source code (comments/IDs and quoting).

• And overlaps with TODO.txt grep-based task scanner (eg. radical.py), shall share concepts.

• Syntax shall borrow TODO.txt where needed:

    (Prio/Order) ISO-Create-Dt ISO-Closed-Dt text @Ctx +Prj meta:value
  

• plus +U_s extensions:

    Local ID Label: text labels `id-title-or-command-ref` <locator/id-ref> #fragment/compoent-id-ref [Is-Member-Of-Id]
  
  Not documented yet. No more (complex) syntax or inferred structure
  shall be used for base version, no double quoting, no segments or nesting.
  
  

Basicly TODO.txt imposes a reduced expressivity for labels and some other Id's, and this could be used to track and sync duplicate entries. Experimentation though is ongoing, but the following correspondence emerges:

  ReadMe.rst:123:# Sync: Other:
  TODO: Sync: <ReadMe.rst> <Other:ReadMe.rst>

git-versioning already uses sentinel lines to hold versions and possibly other ID's per file, and package.y*ml uses it in its preprocessing phase to let it include verbatim or prepared YAML parts.

New functions to syncronize code and to manage sentinel codes is experimented with.

Here, for +U_s some (md) document gen/preproc/assembly may be req.

• Another borrewed concept is named directories or prefixes. Were a v-Id: takes place for a long path. This overlaps with SSH aliases etc.

  TODO: group document these functions somewhere, pd-table etc.

  These Ids should be unique, global IDs for the user-system. Ie. like TODO.txt contexts, and where some contexts correspond to a TODO.txt project as well.