docs: Capitalize “Markdown” consistently.

Signed-off-by: Anders Kaseorg <anders@zulip.com>

docs/contributing/gsoc-ideas.md

@@ -238,8 +238,8 @@ work from the student.
 
 More important to us than specific deliverables in a project proposal
 is a clear body of work to focus on; E.g. if we see a proposal with 8
-markdown processor issues, we'll interpret this as a student excited
-to work on the markdown processor for the summer, even if the specific
+Markdown processor issues, we'll interpret this as a student excited
+to work on the Markdown processor for the summer, even if the specific
 set of 8 issues may not be the right ones to invest in.
 
 ### Focus areas

docs/subsystems/markdown.md

@@ -145,7 +145,7 @@ groups (which depend on data like users' names, IDs, etc.).
 At a backend code level, these are controlled by the `message_realm`
 object and other arguments passed into `do_convert` (`sent_by_bot`,
 `translate_emoticons`, `mention_data`, etc.).  Because
-`python-markdown` doesn't support directly passing arguments into the
+Python-Markdown doesn't support directly passing arguments into the
 Markdown processor, our logic attaches these data to the Markdown
 processor object via e.g. `_md_engine.zulip_db_data`, and then
 individual Markdown rules can access the data from there.

docs/subsystems/performance.md

@@ -305,7 +305,7 @@ messages is intuitively the main feature of a chat service: a message
 sent to 50 users triggers ~50 `GET /events` requests.
 
 A typical message-send request takes 20-70ms, with more expensive
-requests typically resulting from [markdown
+requests typically resulting from [Markdown
 rendering](../subsystems/markdown.md) of more complex syntax.  As a
 result, these requests are not material to Zulip's scalability.
 Editing messages and adding emoji reactions are very similar to

static/js/markdown.js

@@ -211,7 +211,7 @@ export function apply_markdown(message) {
             return quote;
         },
     };
-    // Our python-markdown processor appends two \n\n to input
+    // Our Python-Markdown processor appends two \n\n to input
     message.content = marked(message.raw_content + "\n\n", options).trim();
     message.is_me_message = is_status_message(message.raw_content);
 }

templates/zerver/api/outgoing-webhooks.md

@@ -80,7 +80,7 @@ you would like to send a response message:
 }
 ```
 
-The `content` field should contain Zulip-format markdown.
+The `content` field should contain Zulip-format Markdown.
 
 Note that an outgoing webhook bot can use the [Zulip REST
 API](/api/rest) with its API key in case your bot needs to do

zerver/lib/markdown/__init__.py

@@ -2272,7 +2272,7 @@ class Markdown(markdown.Markdown):
         return treeprocessors
 
     def build_postprocessors(self) -> markdown.util.Registry:
-        # These are the default python-markdown processors, unmodified.
+        # These are the default Python-Markdown processors, unmodified.
         postprocessors = markdown.util.Registry()
         postprocessors.register(markdown.postprocessors.RawHtmlPostprocessor(self), "raw_html", 20)
         postprocessors.register(

zerver/logging_handlers.py

@@ -116,7 +116,7 @@ class AdminNotifyHandler(logging.Handler):
         # prevent the infinite loop of Zulip messages by ERROR_BOT if
         # the outer try block here throws an exception before we have
         # a chance to check the exception for whether it comes from
-        # markdown.
+        # the Markdown processor.
         is_markdown_rendering_exception = True
 
         try:

zerver/openapi/zulip.yaml

@@ -1836,7 +1836,7 @@ paths:
                                 content:
                                   type: string
                                   description: |
-                                    The new content of the message, in the original markdown.
+                                    The new content of the message, in the original Markdown.
                                 rendered_content:
                                   type: string
                                   description: |

zerver/views/realm_playgrounds.py

@@ -17,7 +17,7 @@ def check_pygments_language(var_name: str, val: object) -> str:
     # We don't want to restrict the language here to be only from the list of valid
     # Pygments languages. Keeping it open would allow us to hook up a "playground"
     # for custom "languages" that aren't known to Pygments. We use a similar strategy
-    # even in our fenced_code markdown processor.
+    # even in our fenced_code Markdown processor.
     valid_pygments_language = re.compile(r"^[ a-zA-Z0-9_+-./#]*$")
     matched_results = valid_pygments_language.match(s)
     if not matched_results: