diff --git a/pwiki/parser.js b/pwiki/parser.js index fb18aea..82a9895 100755 --- a/pwiki/parser.js +++ b/pwiki/parser.js @@ -436,21 +436,7 @@ module.BaseParser = { // XXX macros: we are mixing up ast state and parse state... // one should only be used for parsing and be forgotten after // the ast is constructed the other should be part of the ast... - // XXX ASYNC this does not yet work as a replacement for .expand(..), - // not sure why... - // ...seems that this breaks how slots and vars are handled... - // to reproduce: - // new code: - // await p.pwiki.parse('!!! moo') - // -> '!!! ' - // old code: - // await p.pwiki.parse('!!! moo') - // -> 'moo!!! ' - // ...this affects @var(..) and @slot(..) and does not affect @macro(..) - // The problem is that .callMacro(..) is for some execution paths is - // called sync and in some paths after the current execution frame is - // done, i.e. async... - // ...turns out that the problem is in the inconsistent await behavior, + // XXX DOC inconsistent await behavior... // in var macro, as an example, there are two paths: the assign and // the get, the assign calls .parse(..) and awaits for the result // while the get path is "sync", this results in the first exec path @@ -475,7 +461,7 @@ module.BaseParser = { // an await of something does not fix the issue, we need to await // for something significant -- await this.parse('') works, while // await vars[name] does not -- to the contrary of the above example... - // XXX EXPERIMENTAL... + // XXX EXPERIMENTAL -- this seems to be slower than the original version... expand: function(page, ast, state={}){ var that = this ast = ast == null ? @@ -515,6 +501,8 @@ module.BaseParser = { return res } else { return [res] } }) }, + // XXX BUG: this is not called on errors in: + // file:///L:/work/pWiki/pwiki2.html#/Tests/ParseErrorOutputTest function(err){ console.error(err) return page.parse(