diff --git a/docs/contributing/gsoc-ideas.md b/docs/contributing/gsoc-ideas.md index ee978a45a5..1dda671c01 100644 --- a/docs/contributing/gsoc-ideas.md +++ b/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 diff --git a/docs/subsystems/markdown.md b/docs/subsystems/markdown.md index 0f4add95db..15a5e7d6a0 100644 --- a/docs/subsystems/markdown.md +++ b/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. diff --git a/docs/subsystems/performance.md b/docs/subsystems/performance.md index cef37be228..1a9609ce6b 100644 --- a/docs/subsystems/performance.md +++ b/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 diff --git a/static/js/markdown.js b/static/js/markdown.js index 87b4f113b9..b5d42cae2b 100644 --- a/static/js/markdown.js +++ b/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); } diff --git a/templates/zerver/api/outgoing-webhooks.md b/templates/zerver/api/outgoing-webhooks.md index fca7809378..a1155b5750 100644 --- a/templates/zerver/api/outgoing-webhooks.md +++ b/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 diff --git a/zerver/lib/markdown/__init__.py b/zerver/lib/markdown/__init__.py index a808b6e8a9..9d3760894b 100644 --- a/zerver/lib/markdown/__init__.py +++ b/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( diff --git a/zerver/logging_handlers.py b/zerver/logging_handlers.py index 2d9c56405d..47a47e19a9 100644 --- a/zerver/logging_handlers.py +++ b/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: diff --git a/zerver/openapi/zulip.yaml b/zerver/openapi/zulip.yaml index d2da5a1380..ef89ce5193 100644 --- a/zerver/openapi/zulip.yaml +++ b/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: | diff --git a/zerver/views/realm_playgrounds.py b/zerver/views/realm_playgrounds.py index 1735387850..a49190e50b 100644 --- a/zerver/views/realm_playgrounds.py +++ b/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: