Parser 2011/Environment

Every wikitext parsing action takes place within an environment. Calling application must provide an environment object to the parser engine, which allows detecting what else is in the system, what extensions are available, the current time and user info, etc.

The ParserEnvironment defines most of the interface between the Parser system and the host application.

'''In the ParserPlayground extension this is implemented in the MWParserEnvironment JS class.

todo: define specific interfaces on the Environment object for the Parser object to use, in a reasonably abstract manner

Pretty solid stuff
 * Info about the current state
 * (Date) timestamp -- current rendering timestamp
 * (Title) title
 * (string) contentLanguage
 * Info about the wiki as a whole
 * (function(string name)) templateCallback
 * (?) way to fetch Namespace info
 * (?) way to fetch parser function names, aliases, & callbacks -- Wikitext parser/Core parser functions
 * (?) way to fetch parser tag hook names, aliases, & callbacks -- Wikitext parser/Core tag hooks
 * (?) way to plug into localization system for some localizable info
 * (?) way to fetch current-page / current-revision metadata
 * (?) way to fetch configuration of supported linking options
 * (?) way to fetch interwiki & interlanguage configuration, prefixes

Parsing state?
 * At times we'll need to be able to indicate a state at the start of parsing to or from source; such as knowing that we're inside a table cell or inside a template, or on vs not on the start of a line.

Stuff to throw away


 * settings that are now part of HTML-transform stage, not really needed here
 * header numbering
 * thumbnail sizes
 * math rendering mode
 * stub link threshhold
 * image whitelist / bad image blacklist
 * external link target

possible data sources...

Stuff on a current ParserOptions object:
 * (bool) useDynamicDates (kill -- move to app-specific HTML rendering)
 * (bool) interwikiMagic: flag to indicate whether interlanguage links without a ':'-override are taken as metadata (on) or inline links (off)
 * (bool) allowExternalImages (killable? hated feature)
 * (array of strings? regex?) allowExternalImagesFrom
 * enableImageWhitelist (kill -- app-specific HTML rendering)
 * dateFormat -- default date format key (unstable?)
 * (bool) editSection (kill -- app-specific HTML rendering)
 * (bool) allowSpecialInclusion: flag to allow transclusion of Special: pages as pseudo-extensions (??)
 * (bool) tidy (kill this -- always use the tidy style even when we do it manual in future to match Wikipedia behavior by default)
 * (string) interfaceMessage: which language gets used for PLURAL, GRAMMAR, etc parser functions
 * (string) targetLanguage: (overrides the above...? wtf?)
 * (int) maxIncludeSize
 * (int) maxPPNodeCount
 * (int) maxPPExpandDepth
 * (int) maxTemplateDepth
 * (int) removeComments (kill -- preprocessor stuff?)
 * (function) templateCallback -- callback for template source fetching by name!
 * (bool) enableLimitReport -- (kill -- app-specific HTML rendering?)
 * (Date) timestamp -- timestamp used for 27 etc
 * (string) externalLinkTarget -- window target for external links
 * (bool) cleanSignatures (?)
 * (bool) preSaveTransform (kill -- do this in an editing stage post-parse pre-save)
 * (bool) numberHeadings (kill -- app-specific HTML rendering)
 * (bool) math (kill -- replace with presence of tag hook extensions)
 * (bool) thumbSize (kill -- app-specific HTML rendering)
 * (int) stubThreshold (kill -- app-specific HTML rendering)
 * (string) userLang (move to app-specific HTML rendering? Or need this for messagey stuff?)
 * (User) user: access to the currently-viewing user .... should this be exposed at all?
 * (bool) isPreview
 * (bool) isSectionPreview
 * (bool) isPrintable (kill -- HTML output issue? regular version should always be renderable with print stylesheets for printable version)
 * (string) extraKey (cache thing)
 * (function) onAccessCallback (internally used to check with options are enabled that may affect rendering for cache key stuff)

Environment state vs page target state
Quick ref to Special:Code/MediaWiki/90858 -- discussion of whether page content direction should be passed in through ParserOptions or retrieved by the parser from the page title. It feels like page metadata, so should probably come along in some sort of block that may want more than just title in future.