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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitext-l _______________________________________________ Wikitext-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitext-l
