Waylan Limberg

> For normal inline patterns, `attr_list` would need to have a more precise pattern to avoid gobbling a whole line. Again, I don't know if `attr_list` plans to fix this...

@squidfunk thanks for the update. Given the fact that (1) there is no officially supported need for it, (2) the proposed modification would introduce a inconsistency between attr_lists on fenced...

Okay, so the symbol type code span is being included in the index. I failed to recognize that as the body text of the code span wasn't included in the...

> While we investigate this issue, you can set `show_symbol_type_heading: false` in mkdocs.yml Actually, this setting makes no difference. To be clear, changing the setting does remove the symbol type...

> About symbols still appearing in the search results, try also setting `show_symbol_type_toc: false` That fixes the issue. The `show_symbol_type_heading` option has no bearing on the issue either way, only...

I just deployed the docs with the changes in #1434 and [search results](https://python-markdown.github.io/search.html?q=ESCAPED_CHARS) are better (they are actually usable). However, we still have the issue with the module names not...

> However, we still have the issue with the module names not being striped of tags before being indexed. Therefore, this issue is still unresolved. Upon further investigation, it appears...

> It is also possible that the TOC extension itself needs better sanitation. After I posted that I remembered that the type symbols are added by mkdocsstrings after Markdown is...

> we still have the issue with the module names not being striped of tags before being indexed. After some investigation, it is now clear that the as-yet unresolved problem...

> > I wonder if perhaps mkdocsstrings needs to take a different approach here so as not to dirty the TOC and page title. > > I'm open to any...