Only show authors' email addresses if so configured in git-authors

[fghaas]

Honour the git-authors plugin's option to render the authors' names as links pointing to their email address:

• If the git-authors plugin is enabled and its show_email_address option is not set, or is set to true¹, render the author's name as a mailto: link.
• If the git-authors plugin is enabled and its show_email_address option is set to false, render the author's name in plain text with no link.
• If the git-authors plugin is not enabled (or not installed), don't show author information.

Footnotes

1. The current default for show_email_address in the plugin is true. If that default ever changes in the future, then the logic for showing the mailto: link would change accordingly. ↩

[squidfunk]

Minor cosmetic changes, otherwise good!

[squidfunk]

This is not really readable. Please adhere to the surrounding formatting, so move things onto separate lines. There's also no need to put show_email_address in a separate variable I think.

[fghaas]

Roger that, updated.

[squidfunk]

One more spot: We don't need whitespace control here. Please remove the - on all tags that you added.

[fghaas]

Does that include the one instance of {{- author.name -}} that I duplicated? In other words, should the hyphens be dropped from that one as well?

[squidfunk]

Yes. The following line is the only line where this is necessary, because we want the , to stick to the author name, but this is a line you did not touch, which is why I meant to remove them from all lines you touched.

mkdocs-material/src/templates/partials/source-file.html

Line 60 in 2ca5cf0

{%- if loop.revindex > 1 %}, {% endif -%}

[fghaas]

Also, I am not so sure about that. If I drop all instances of - that I introduced here, then if show_email_address is true, I end up with

    <nav>
      
        
          <a href="mailto:john.doe@example.com">John Doe</a>
        , 
        
          <a href="mailto:jane.doe@example.com">Jane Doe</a>
        
    </nav>

And I'm pretty sure we don't want that comma on its own line, because it gets rendered as

John Doe , Jane Doe

... and the thus-appearing extra whitespace before the comma is extraneous.

As the patch is currently proposed, what we end up with is

    <nav>
        
          <a href="mailto:john.doe@example.com">John Doe</a>, 
          <a href="mailto:jane.doe@example.com">Jane Doe</a>
    </nav>

... which is what we want, I think. Would you agree?

[fghaas]

I've just pushed 7f0cdd2 which is the most minimal patch that I can think of, with no whitespace management added at all. But that introduces the extra space before the comma, no matter if we're rendering a link or not. So please do not merge that as-is.

[fghaas]

That fixes things only for show_email_address: false; but still breaks (i.e. introduces the extraneous whitespace) for the default of show_email_address: true.

[fghaas]

This does the right thing, regardless of how show_email_address is set:

       {% for author in authors %}
+        {%- if git_authors.config.show_email_address %}
         <a href="mailto:{{ author.email }}">
           {{- author.name -}}
         </a>
+        {%- else -%}
+          {{- author.name -}}
+        {% endif -%}
         {%- if loop.revindex > 1 %}, {% endif -%}
       {% endfor %}

Okay if I update my topic branch with that?

[squidfunk]

I'm sure you don't need all of those whitespace control characters, but okay, let's keep the whitespace control. I'll look into in the future. We should keep whitespace control to a minimum, and only use it where absolutely necessary.

[fghaas]

I sympathise with that, but if you instruct me to "remove the - on all tags that [I] added" and simultaneously "we want the , to stick to the author name", I can only do one xor the other. :)

[squidfunk]

Haha yeah, sorry for that. Entirely my fault. I'm sorry for the back and forth. Is it okay to merge now?

[fghaas]

Is it okay to merge now?

Well I'd still been trying to wrap my head around how to add tests for this, hence the Draft mode. I've looked at what I think is the relevant part of the docs, but most of those recommendations don't seem to apply here since neither mkdocs-material's own docs nor the examples repo use git-authors.

I've tested it against the repo I co-maintain (citynetwork/docs#257) and there all our tests pass. Is that sufficient?

[squidfunk]

Yes, that should be fine. Thanks!