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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitext-l