Currently, the first @language declaration in an @root node (or its nearest ancestor) wins, but it is superseded by the first (and only the first) @comment in the node or (or its nearest ancestor), if any.
Because I want to deal with multiple languages in a single node (e.g., html and javascript) I don't find this behavior useful, and here propose an alternative. I am going to ignore colorization behavior. I propose that, for the purposes only of @root tangling and untangling, "@language" be a synonym for the @comment directive appropriate to that language. I further propose that tangling be governed by the closest preceding @comment or @language directive, either in the node or as encountered in its closest parent node. Because multiple <<section>> references (to the same section) may occur in a node body and because nodes may contain multiple section definitions, a definition of "closest" which involves proximity to <<section>> references would be overwhelmingly complex and ambiguous; thus for parent nodes, "closest" is defined as nearest to the bottom of the body text, or, failing that, the last occurrence in the headline, closer parents having precedence over more distance ones (i.e., stop looking as soon as you find an @comment or @language directive as you search backwards). When tangling, the importance of the @comment/@lanuage is to generate sentinels. A section may need a starting sentinel in one comment convention and the end in a different comment. E.g., =========================== @language html <<Text section>> <<Javascript section>> <<Second text section>> <<Text section>>= Hi. This is html text. @comment // <script language="javascript"><!-- <<Javascript section>>= var s = "string"; @comment <!-- --> --></script> <<Second text section>>= This is a second piece of html text. =========================== tangles into =========================== <!-- << Text section >> --> Hi. This is html text. <script language="javascript"><!-- // -- end -- << Text section >> // << Javascript section >> var s = "string"; --></script> <<!-- -- end -- << Javascript section >> --> <<!-- << Second text section >> --> This is a second piece of html text. <<!-- -- end -- << Second text section >> --> =================================== The driving factor for this design is that Leo cannot be expected to know how to transition from one language to another, where the number of possible transitions is O(n^2) in the number of languages. Thus the human must be able to provide transition information. I invite you to critique this proposal for a couple days while I try to poke holes in it myself; I expect untangling will be interesting. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
