I solved it by recognizing a new undocumented modifier in the XBetza parser, which sets the range for that particular step to 666. Further downstream in the compiling process this 666 is recognized as synonymous for 1 (i.e. a leap), but flags that this leg is a candidate for elimination (but otherwise, i.e. if a slide directly follows, would have mpo mode). The preprocessor that converts bracket notation to XBetza uses this new modifier for the intermediate steps it uses to make the initial leg commensurate with later legs.
Explicit use of this new modifier is not recommended; it might disappear once direct parsing of bracket notation is implemented.
I solved it by recognizing a new undocumented modifier in the XBetza parser, which sets the range for that particular step to 666. Further downstream in the compiling process this 666 is recognized as synonymous for 1 (i.e. a leap), but flags that this leg is a candidate for elimination (but otherwise, i.e. if a slide directly follows, would have mpo mode). The preprocessor that converts bracket notation to XBetza uses this new modifier for the intermediate steps it uses to make the initial leg commensurate with later legs.
Explicit use of this new modifier is not recommended; it might disappear once direct parsing of bracket notation is implemented.
Currently betzaNew.js only!