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(