rearchitect the parser to be more modern, traditional, and extensible

Migrated issue, originally created by zaxebo1 zaxebo1 (@zaxebo1)

jinja2 has configurable syntax for delimiters. If you are generating LaTeX or other formats with Jinja2 you can change the delimiters to something that integrates better into the LaTeX markup. see at

http://svn.python.org/projects/external/Jinja-1.2/docs/src/altsyntax.txt
https://gist.github.com/lost-theory/3925738

for example: How Flask configures jinja templates for a configurable delimiter

 jinja_options = Flask.jinja_options.copy()
jinja_options.update(dict(
block_start_string='<%',
block_end_string='%>',
variable_start_string='%%',
variable_end_string='%%',
comment_start_string='<#',
comment_end_string='#>',
)) 

=========================================================

**NOW, My Feature Request is that

FEATURE REQUEST A)
can we have optionally configurable delimiters in mako too, like jinja above (VVIMP)

FEATURE REQUEST B)
like Preprocess ( https://code.google.com/p/preprocess/ ) or cog ( http://nedbatchelder.com/code/cog/ ), can we have an enhancement where the mako statements can be hidden inside the host language(say,latex etc) comments like /* */ or, # .
A mako statement is a comment (as appropriate for the language of the file being preprocessed). This way the mako statements do not make an unpreprocessed file syntactically incorrect for the IDEs. The exception to this can be ${variablename} statements , but other syntaxes like <% and % etc can be OPTIONALLY inside host language comments, if the mako user configures it as such.

**

I love mako very much and would like it embed it inside latex,sql and other host languages source code easily. :-)

The issue names no files, tests, or specific Mako entry points. Start by locating Mako's parser and syntax-configuration entry points, then clarify whether configurable delimiters, host-language comment wrapping, or both are in scope. Done should include a decided design and tests covering the supported configuration.