I've started throwing some initial notes into the various sub-sections listed here: http://www.mediawiki.org/wiki/Future/Parser_plan
Adding very brief stubs describing the various default & some of the common extension parser function & tag hooks, the beginnings of some notes on the parser<->context interface (which will need to provide access to template fetches, page lookups, and various information such as language, available hooks of various types, current time, etc).
http://www.mediawiki.org/wiki/Wikitext_parser/Context
http://www.mediawiki.org/wiki/Wikitext_parser/Core_tag_hooks http://www.mediawiki.org/wiki/Wikitext_parser/Core_parser_functions
The function & tag hook descriptions can use filling out, and anything that looks tricky to implement should get explicitly noted! We know that some functions will not be fully implemented in the JavaScript editing versions (no immediate need to do a standalone Latex interpreter!) while others will probably need to be tested in this environment early on like the if/switch stuff.
These will also need sane ways to represent them during editing -- suggestions are welcome!
I've been updating the ParserPlayground gadget files as an in-SVN version Extension:ParserPlayground -- you can enable this version on any local trunk test wiki by pulling it from extensions SVN and enabling it. This lets us keep the master copy versioned more easily than just keeping the pages on MediaWiki.org as gadget files. There are a few changes such as making the inspector mode enableble/disablable and when it's off offering a primitive editing feature, starting to integrate into the WikiEditor toolbar infrastructure.
The gadget on MediaWiki.org will switch over to use that later this week (prototyped by my updates to the CodeEditor gadget and extension last couple weeks); it still needs to be made a little more pluggable, retain its state better, and have a more editing-centric rendering output.
http://www.mediawiki.org/wiki/Extension:ParserPlayground
-- brion
Hi,
I just have some terminology nitpicking regarding the "Context" page.
I would prefer to use the word "environment" rather than "context", because "context" could also refer to the grammatical context so it might cause confusion.
What exactly is meant by "parser state"?
On the page is written that the parser state needs to indicate that the current parsing takes place in content originating from a template. But "parser state" is a term that I would use to refer to the state of the single pass parser that produce the syntax tree. (I believe that any conforming parser will have to be divided into preprocessor (multiple passes), parser (one pass), postprocessing.)
Preprocessing of a template is different from preprocessing the top level document, (the behavior of <noinclude> etc. is different). But I would rather talk about different "preprocessor configurations" for these different situations.
Keeping track of which pieces of text that were produced by preprocessor expansions is desirable, however. For instance, if leaf nodes produced from preprocessed text are marked "read only", it will be possible to do simple modificiations on the syntax tree and serialize it back to wikitext and get precicely the original wikitext with expected modifications. So, such information could be part of the parser state.
Best regards,
Andreas Jonsson
2011-06-28 02:44, Brion Vibber skrev:
I've started throwing some initial notes into the various sub-sections listed here: http://www.mediawiki.org/wiki/Future/Parser_plan
Adding very brief stubs describing the various default & some of the common extension parser function & tag hooks, the beginnings of some notes on the parser<->context interface (which will need to provide access to template fetches, page lookups, and various information such as language, available hooks of various types, current time, etc).
http://www.mediawiki.org/wiki/Wikitext_parser/Context
http://www.mediawiki.org/wiki/Wikitext_parser/Core_tag_hooks http://www.mediawiki.org/wiki/Wikitext_parser/Core_parser_functions
The function & tag hook descriptions can use filling out, and anything that looks tricky to implement should get explicitly noted! We know that some functions will not be fully implemented in the JavaScript editing versions (no immediate need to do a standalone Latex interpreter!) while others will probably need to be tested in this environment early on like the if/switch stuff.
These will also need sane ways to represent them during editing -- suggestions are welcome!
I've been updating the ParserPlayground gadget files as an in-SVN version Extension:ParserPlayground -- you can enable this version on any local trunk test wiki by pulling it from extensions SVN and enabling it. This lets us keep the master copy versioned more easily than just keeping the pages on MediaWiki.org as gadget files. There are a few changes such as making the inspector mode enableble/disablable and when it's off offering a primitive editing feature, starting to integrate into the WikiEditor toolbar infrastructure.
The gadget on MediaWiki.org will switch over to use that later this week (prototyped by my updates to the CodeEditor gadget and extension last couple weeks); it still needs to be made a little more pluggable, retain its state better, and have a more editing-centric rendering output.
http://www.mediawiki.org/wiki/Extension:ParserPlayground
-- brion
Wikitext-l mailing list Wikitext-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitext-l
wikitext-l@lists.wikimedia.org