Thanks for the PR! The code changes look excellent, but I'm not sure yet if this is a direction we want to go towards.
So far I have deliberately kept the CLI surface as small as possible. It doesn't take much imagination that we could also add a switch to add a logo, add a switch to pass the version number, add a switch to hide specific members, add a switch to embed MathJax, etc. That being said, I think your point that some folks may not like learning (a bit of) Jinja2 is fair.

Long story short, let me think about this for a few days. We could also add a short section to the docs with a small example on how to override the view source macro (https://github.com/mitmproxy/pdoc/blob/main/examples/custom-template/module.html.jinja2 already has one). Then again, maybe we do want to add a "render options" argument group and put more stuff there.

I appreciate the concern over the commandline interface ballooning into something ridiculous but I wonder if there's a middle-ground to be reached here. I've not thought very much about whether this is actually a sensible implementation or even if it is something pdoc is designed to support, but it's something to think about at least:

If you use pdoc as a module then the configure function is there to set up the options as well. This interface could potentially be extended to accept a dictionary of {"flag": "value"} (or accept **kwargs), which would then update the env object with those values:

def configure(*, 
        template_directory=None, docformat=None, edit_url_map=None, show_source=True,  # Values that have commandline options
        **kwargs  # For config options that either the user wants to use in the default templates or add to their own templates
):
    ...
    env.globals["edit_url_map"] = edit_url_map or {}
    env.globals["docformat"] = docformat
    env.globals["show_source"] = show_source
    for key, value in kwargs.items():
        env.globals[key] = value

With this approach, the message could be:

• pdoc supports a limited set of commandline options for the most important switches
• pdoc supports switches for disabling loads of stuff in the output if you call pdoc as a library
• pdoc supports outputting in literally any format if you know enough about Jinja2 to subclass or write a new template

With this tiered approach, the module can support: users who just want to generate docs from some existing Python they've found lying around; users who wrote a Python tool with docs (and are therefore comfortable with writing pure Python); and advanced users who either know Jinja already or are willing to learn to get a customised output.

Thanks again @Bruntaz! This was really useful feedback and made me reconsider the CLI situation. I've just merged #288, which among other things adds a --show-source/--no-show-source toggle. 😃