fix for #215: Fix title and nav parsing

[AnvithLobo]

• allow macros in meta variables
• allow automatic parsing of title by mkdocs as explicitly assigning page.title will override that.
• Fix macro parsing in nested nav Sections
• Be unopinionated and let just parse macros. Let Mkdocs handle title priority

[fralau]

Thank you for solving the conflicts.

I looked at your solution and I see elegance in it (modifications are well-localized). That is definitely an advantage.

What will matter, in final analysis, is whether it solves the issue or not, without creating new ones.

I have two objections at this stage:

1. I see only processing of variables, in the rendering. What about expressions containing Jinja2 macros and filters?
2. Do you have a theory of why it would be sufficient to intervene at the stage of on_nav, and it is no longer necessary at on_page_markdown? What about the processing of page variables (e.g. defined in the page's YAML front-matter)?

[fralau]

I see only processing of variables. What about macros and filters?

[AnvithLobo]

This just mimics the current behavior of the existing jinja2 rendering code for the page.

mkdocs-macros-plugin/mkdocs_macros/plugin.py

Lines 580 to 583 in f97565f

	md_template = self.env.from_string(markdown)
	# Execute the jinja2 template and return
	return md_template.render(**page_variables)

Unless I misread the code the on_config method should load all the filters and macros to self.env and self.variables right? and page_variables in render is just a copy of self.variables. So all macros and filters should work fine like usual.

mkdocs-macros-plugin/mkdocs_macros/plugin.py

Lines 696 to 716 in f97565f

	# finally build the environment:
	self.env = Environment(**env_config)
	# -------------------
	# Process macros
	# -------------------
	# reference all macros
	self.variables['macros'] = copy(self.macros)
	# add the macros to the environment's global (not to the template!)
	self.env.globals.update(self.macros)
	# -------------------
	# Process filters
	# -------------------
	# reference all filters, for doc [these are copies, so no black magic]
	# NOTE: self.variables is reflected in the list of variables
	# in the jinja2 environment (same object)
	self.variables['filters'] = copy(self.filters)
	self.variables['filters_builtin'] = copy(self.env.filters)
	# update environment with the custom filters:
	self.env.filters.update(self.filters)

Let me know if i'm wrong. I'll look into it a bit more then.

[fralau]

Same remark here (variables and not filters and macros).

[AnvithLobo]

2. Do you have a theory of why it would be sufficient to intervene at the stage of on_nav, and it is no longer necessary at on_page_markdown? What about the processing of page variables (e.g. defined in the page's YAML front-matter)?

This is only for the nav items. Trying to render nav items from on_page_markdown is not ideal. As we would have to get the page and it's current nav then walk up the tree to find the first parent and then again walk down the tree all the way down to render the nav items.
First this wouldn't be elegant nor efficient. As we would need to do this for every page.
But If we only consider the last parent and try to render it's child. We will miss rendering any empty sections with no pages currently linked to that section.

The only disadvantage of rendering Nav items on on_nav instead of on_page_markdown is that we will miss out on any meta variables defined in the page. But this is more trouble than it is worth solving IMO.