diff --git a/docs/README.md b/docs/README.md index 707891ebc2..d6aca053af 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,6 +1,6 @@ -# Zulip markdown documentation hosted elsewhere +# Zulip Markdown documentation hosted elsewhere -The markdown files in this directory ( /zulip/docs ) are not intended +The Markdown files in this directory ( /zulip/docs ) are not intended to be read on GitHub. Instead, visit our [ReadTheDocs](https://zulip.readthedocs.io/en/latest/index.html) to read the Zulip documentation. diff --git a/docs/contributing/gsod-ideas.md b/docs/contributing/gsod-ideas.md index 2e4132e807..a817827542 100644 --- a/docs/contributing/gsod-ideas.md +++ b/docs/contributing/gsod-ideas.md @@ -71,7 +71,7 @@ process. For many of our project ideas, you'll be working inside a Zulip development environment (because the documentation is implemented as -markdown in the main Zulip repository, and can be previewed using +Markdown in the main Zulip repository, and can be previewed using tools in the Zulip development environment). See [our documentation on documentation systems](../documentation/overview.md) for details on our various existing documentation systems. @@ -188,7 +188,7 @@ started.). Once you have several PRs merged (or at least one significant PR merged, or the equivalent of this for projects that don't involve -writing markdown code), you can start discussing with the Zulip +writing Markdown code), you can start discussing with the Zulip development community the project you'd like to do, and develop a specific project plan. We recommend discussing what you're thinking in public streams on chat.zulip.org, so it's easy to get quick @@ -271,7 +271,7 @@ most cases, our documentation explains how to accomplish a task in the Zulip webapp, but doesn't cover how to do those tasks in Zulip's mobile and beta terminal apps. -We have recently built a nice markdown-based system to make it easy to show +We have recently built a nice Markdown-based system to make it easy to show information for multiple platforms in a single tabbed widget. An example article using this widget is [logging in](https://zulip.com/help/logging-in). This project will diff --git a/docs/documentation/api.md b/docs/documentation/api.md index 0d0c9f6bb2..5f1246d85b 100644 --- a/docs/documentation/api.md +++ b/docs/documentation/api.md @@ -30,7 +30,7 @@ Our API documentation is defined by a few sets of files: [OpenAPI configuration](../documentation/openapi.md) at `zerver/openapi/zulip.yaml`. * The top-level templates live under `templates/zerver/api/*`, and are - written using the markdown framework that powers our [user + written using the Markdown framework that powers our [user docs](../documentation/user.md), with some special extensions for rendering nice code blocks and example responses. We expect to eventually remove most of these files where it is possible to @@ -268,16 +268,16 @@ above. comments. The lines inside these comments are what will be displayed as the code example on our `/api` page. -1. Finally, write the markdown file for your API endpoint under +1. Finally, write the Markdown file for your API endpoint under `templates/zerver/api/`. This is usually pretty easy to template off existing endpoints; but refer to the system explanations above for details. -1. Add the markdown file to the index in `templates/zerver/help/include/rest-endpoints.md`. +1. Add the Markdown file to the index in `templates/zerver/help/include/rest-endpoints.md`. 1. Test your endpoint, pretending to be a new user in a hurry, by visiting it via the links on `http://localhost:9991/api` (the API - docs are rendered from the markdown source files on page load, so + docs are rendered from the Markdown source files on page load, so just reload to see an updated version as you edit). You should make sure that copy-pasting the code in your examples works, and post an example of the output in the pull request. @@ -287,7 +287,7 @@ above. ## Why a custom system? Given that our documentation is written in large part using the -OpenAPI format, why maintain a custom markdown system for displaying +OpenAPI format, why maintain a custom Markdown system for displaying it? There's several major benefits to this system: * It is extremely common for API documentation to become out of date diff --git a/docs/documentation/user.md b/docs/documentation/user.md index 9c4e990a0e..7445c520ac 100644 --- a/docs/documentation/user.md +++ b/docs/documentation/user.md @@ -39,7 +39,7 @@ form `/help/foo`; with special cases for `/help/` going to `index.md` and are usually linked from `static/images/help/`. This means that you can contribute to the Zulip user documentation by just -adding to or editing the collection of markdown files under +adding to or editing the collection of Markdown files under `templates/zerver/help`. If you have the Zulip development environment setup, you simply need to reload your browser on `http://localhost:9991/help/foo` to see the latest version of `foo.md` @@ -100,7 +100,7 @@ your documentation to help improve its readability: * Since raw HTML is supported in Markdown, you can include arbitrary HTML/CSS in your documentation as needed. -* Code blocks allow you to highlight syntax, similar to Zulip's own markdown. +* Code blocks allow you to highlight syntax, similar to Zulip's own Markdown. * Anchor tags can be used to link to headers in other documents. * [Images](#images) of Zulip UI can be added to documentation. * Inline [icons](#icons) used to refer to features in the Zulip UI. @@ -108,7 +108,7 @@ HTML/CSS in your documentation as needed. documentation. * You can create special highlight warning blocks using [tips and warnings](#tips-and-warnings). -* You can create tabs using [markdown tab switcher](#tab-switcher). +* You can create tabs using [Markdown tab switcher](#tab-switcher). ### Images @@ -232,7 +232,7 @@ should be formatted as a continuation of a numbered step. ### Tab Switcher -Our markdown processor supports easily creating a tab switcher widget +Our Markdown processor supports easily creating a tab switcher widget design to easily show the instructions for different [platforms](https://zulip.com/help/logging-out) in user docs, languages in API docs, etc. To create a tab switcher, write: diff --git a/docs/overview/changelog.md b/docs/overview/changelog.md index ece8a3960b..ca6ec3b785 100644 --- a/docs/overview/changelog.md +++ b/docs/overview/changelog.md @@ -111,9 +111,9 @@ in bursts. - Added documentation for several more API endpoints. - Added new email address visibility option hiding real email addresses from organization administrators in the Zulip UI. -- Added new "Mention time" markdown feature to communicate about times +- Added new "Mention time" Markdown feature to communicate about times in a timezone-aware fashion. -- Added new "Spoiler" markdown feature to hide text until interaction. +- Added new "Spoiler" Markdown feature to hide text until interaction. - Added a new API that allows the mobile/desktop/terminal apps to open uploaded files in an external browser that may not be logged in. - Added several database indexes that significantly improve @@ -164,7 +164,7 @@ in bursts. - Improved UI for picking which streams to invite new users to. - Improved UI for reviewing one's muted topics. - Improved UI for message edit history. -- Fixed many minor issues with Zulip's markdown processors. +- Fixed many minor issues with Zulip's Markdown processors. - Fixed many subtle issues with the message editing UI. - Fixed several subtle issues with the default nginx configuration. - Fixed minor issues with various keyboard shortcuts. @@ -222,7 +222,7 @@ in bursts. settings system to be more maintainable. - This release largely completes the SCSS refactoring of the codebase. - Replaced our CasperJS frontend integration test system with Puppeteer. -- Extracted the typeahead and markdown libraries for reuse in the +- Extracted the typeahead and Markdown libraries for reuse in the mobile apps. - Removed the legacy websockets-based system for sending messages. This system was always a hack, was only ever used for one endpoint, and @@ -372,7 +372,7 @@ details. to existing Slack/HipChat/Gitter import tools). Slack import now supports importing data only included in corporate exports, including private messages and shared channels. -- Added markdown support and typeahead for mentioning topics. +- Added Markdown support and typeahead for mentioning topics. - Email notifications have been completely redesigned with a minimal, readable style inspired by GitHub's email notifications. - We merged significant preparatory work for supporting RHEL/CentOS in @@ -468,7 +468,7 @@ lose the setting and need to re-enable it. - Added a new setting to control whether inactive streams are demoted. - Added webapp support for new desktop app features: inline reply from notifications, and detecting user presence from OS APIs. -- Added markdown support for headings, implemented using `# heading`, +- Added Markdown support for headings, implemented using `# heading`, and removed several other unnecessary differences from CommonMark. - Added local echo when editing messages for a more responsive experience. - Changes to global notification settings for stream messages now @@ -497,7 +497,7 @@ lose the setting and need to re-enable it. - The administrative UI for managing bots now nicely links to the bot's owner. - Restructured "private messages" widget to have a cleaner design. -- Significantly improved performance of the backend markdown processor. +- Significantly improved performance of the backend Markdown processor. - Significantly improved Help Center documentation of dozens of features. - Simplified and internationalized some notification bot messages. - The compose box placeholder now shows users active status. @@ -507,7 +507,7 @@ lose the setting and need to re-enable it. - Improved default nginx TLS settings for stronger security. - Improved UI of administrative user management UI. - Improved error messages for various classes of invalid searches. -- Improved styling of both markdown unordered and numbered lists. +- Improved styling of both Markdown unordered and numbered lists. - Compose typeahead now autofills stream field if only subscribed to one stream. - Bot users can now post to announcement-only streams if their owners @@ -552,7 +552,7 @@ lose the setting and need to re-enable it. sent to a private stream with shared history before the current user joined that stream. - Fixed several subtle real-time sync issues with "stream settings". -- Fixed a few subtle markdown processor bugs involving emoji. +- Fixed a few subtle Markdown processor bugs involving emoji. - Fixed several issues where Linkifiers validation was overly restrictive. - Fixed several rare/minor UI consistency issues in the left sidebar. - Fixed issues involving saving a message edit before file upload completes. @@ -712,7 +712,7 @@ and is enabled by default in that case. To disable it, set - Added internationalization for outgoing emails. - Added a ReviewBoard integration, and improved numerous existing integrations. - Added support for multi-line messages for the /me feature. -- Added markdown rendering of text when displaying custom profile fields. +- Added Markdown rendering of text when displaying custom profile fields. - Added "silent mentions" syntax (`@_**Tim Abbott**`), which show visually, but don't trigger a notification to the target user. - Added support for using lightbox in compose preview. @@ -720,7 +720,7 @@ and is enabled by default in that case. To disable it, set fixes a common source of confusion for new users. - Suppressed notifications when quoting a message mentioning yourself. - Message editing now has the compose widgets for emoji, video calls, etc. -- Message editing now has a markdown preview feature just like compose. +- Message editing now has a Markdown preview feature just like compose. - Message editing now uses same "enter-sends" behavior as compose. - Organization administrators can now edit users' custom profile fields. - Optimized performance of data import from Slack, HipChat, etc. @@ -973,7 +973,7 @@ Zulip installations; it has minimal changes for existing servers. - Added new ctrl+B, ctrl+I, ctrl+L compose shortcuts for inserting common syntax. - Added warning when linking to a private stream via typeahead. -- Added support for automatically-numbered markdown lists. +- Added support for automatically-numbered Markdown lists. - Added a big warning when posting to #announce. - Added a notification when drafts are saved, to make them more discoverable. @@ -1014,7 +1014,7 @@ Zulip installations; it has minimal changes for existing servers. by last modification, not creation. - Removed the legacy "Zulip labs" autoscroll_forever setting. It was enabled mostly by accident. -- Removed some long-deprecated markdown syntax for mentions. +- Removed some long-deprecated Markdown syntax for mentions. - Added support for clicking on a mention to see a user's profile. - Links to logged-in content in Zulip now take the user to the appropriate upload or view after a user logs in. @@ -1117,7 +1117,7 @@ This is a security release, with a handful of cherry-picked changes since 1.7.1. All Zulip server admins are encouraged to upgrade promptly. -- CVE-2018-9986: Fix XSS issues with frontend markdown processor. +- CVE-2018-9986: Fix XSS issues with frontend Markdown processor. - CVE-2018-9987: Fix XSS issue with muting notifications. - CVE-2018-9990: Fix XSS issue with stream names in topic typeahead. - CVE-2018-9999: Fix XSS issue with user uploads. The fix for this @@ -1310,7 +1310,7 @@ running a version from before 1.7 should upgrade directly to 1.7.1. included in a single missed-message email. - Fixed issues with inconsistent visual display of @-all mentions. - Fixed zombie process leaks on servers with <4GB of RAM. -- Fixed markdown previews of /me messages. +- Fixed Markdown previews of /me messages. - Fixed a subtle bug involving timestamps of locally echoed messages. - Fixed the behavior of key combintions like Ctrl+Enter in the compose box. - Worked around Google Compute Engine's default boto configuration, @@ -1373,7 +1373,7 @@ Zulip apps. * Added Basecamp, Gogs, Greenhouse, Home Assistant, Slack, Splunk, and WordPress webhook integrations. -* Added LaTeX support to the markdown processor. +* Added LaTeX support to the Markdown processor. * Added support for filtering branches to all Git integrations. * Added read-only access to organization-level settings for all users. * Added UI for managing muted topics and uploaded files. @@ -1388,7 +1388,7 @@ Zulip apps. * Added several new permissions-related organization settings. * Added new endpoint for fetching presence data, useful in employee directories. * Added typeahead for language for syntax highlighting in code blocks. -* Added support for basic markdown in stream descriptions. +* Added support for basic Markdown in stream descriptions. * Added email notifications on new Zulip logins. * Added security hardening before serving uploaded files. * Added new PRIVACY_POLICY setting to provide a Markdown privacy policy. @@ -1412,7 +1412,7 @@ Zulip apps. * Improved search typeahead to support group private messages. * Improved logic for when the compose box should open/close. * Improved lightbox to support scrolling through images. -* Improved markdown support for bulleted lists. +* Improved Markdown support for bulleted lists. * Improved copy-to-clipboard support in various places. * Improved subject lines of missed message emails. * Improved handling of users trying to login with OAuth without an account. @@ -1486,7 +1486,7 @@ Zulip apps. #### Full feature changelog - Added an emoji picker/browser to the compose box. -- Added markdown preview support to the compose box. +- Added Markdown preview support to the compose box. - Added a new analytics system to track interesting usage statistics. - Added a /stats page with graphs of the analytics data. - Added display of subscriber counts in Manage streams. @@ -1495,7 +1495,7 @@ Zulip apps. - Added support for copying subscribers from existing streams on creation. - Added several new search/filtering UI elements. - Added UI for deactivating your own Zulip account. -- Added support for viewing the raw markdown content of a message. +- Added support for viewing the raw Markdown content of a message. - Added support for deploying Zulip with subdomains for each realm. This entailed numerous changes to ensure a consistent experience. - Added support for (optionally) using PGRoonga to support full-text @@ -1522,12 +1522,12 @@ Zulip apps. whether Zulip is optimized around protecting user privacy vs. administrative control. - Added #**streamName** syntax for linking to a stream. -- Added support for viewing markdown source of messages. +- Added support for viewing Markdown source of messages. - Added setting to always send push notifications. - Added setting to hide private message content in desktop notifications. - Added buttons to download .zuliprc files. -- Added italics and strikethrough support in markdown implementation. +- Added italics and strikethrough support in Markdown implementation. - Added errors for common installations mistakes (e.g. too little RAM). - Added a new /authors page showing the contributors to the current Zulip version. @@ -1552,7 +1552,7 @@ Zulip apps. - Fixed several transactionality bugs (e.g. in Huddle creation). - Fixed missed-message email configuration error handling. - Fixed annoying @-mentions in Jira integration. -- Fixed various mismatches between frontend and backend markdown +- Fixed various mismatches between frontend and backend Markdown implementations. - Fixed various popover-related UI bugs. - Fixed duplicate notifications with multiple open Zulip tabs. @@ -1621,7 +1621,7 @@ Zulip apps. - Added year to timestamps in message interstitials for old messages. - Added GitHub authentication (and integrated python-social-auth, so it's easy to add additional social authentication methods). -- Added TERMS_OF_SERVICE setting using markdown formatting to configure +- Added TERMS_OF_SERVICE setting using Markdown formatting to configure the terms of service for a Zulip server. - Added numerous hooks to puppet modules to enable more configurations. - Moved several useful puppet components into the main puppet @@ -1670,7 +1670,7 @@ Zulip apps. - Fixed old deployment directories leaking indefinitely. - Fixed need to manually add localhost in ALLOWED_HOSTS. - Fixed display positioning for the color picker on subscriptions page. -- Fixed escaping of Zulip extensions to markdown. +- Fixed escaping of Zulip extensions to Markdown. - Fixed requiring a reload to see newly uploaded avatars. - Fixed @all warning firing even for `@all`. - Restyled password reset form to look nice. diff --git a/docs/production/upgrade-or-modify.md b/docs/production/upgrade-or-modify.md index 20959a855b..f40d07b1c2 100644 --- a/docs/production/upgrade-or-modify.md +++ b/docs/production/upgrade-or-modify.md @@ -132,7 +132,7 @@ help](https://chat.zulip.org/#narrow/stream/31-production-help) in the [Zulip development community server](../contributing/chat-zulip-org.md) for best-effort help. Please include the relevant error output from the above logs in a -[markdown code +[Markdown code block](https://zulip.com/help/format-your-message-using-markdown#code) in any reports. diff --git a/docs/subsystems/dependencies.md b/docs/subsystems/dependencies.md index c2153452ef..09dfcfaf85 100644 --- a/docs/subsystems/dependencies.md +++ b/docs/subsystems/dependencies.md @@ -269,7 +269,7 @@ Zulip uses the [iamcal emoji data package][iamcal] for its emoji data and sprite sheets. We download this dependency using `npm`, and then have a tool, `tools/setup/build_emoji`, which reformats the emoji data into the files under `static/generated/emoji`. Those files are in -turn used by our [markdown processor](../subsystems/markdown.md) and +turn used by our [Markdown processor](../subsystems/markdown.md) and `tools/update-prod-static` to make Zulip's emoji work in the various environments where they need to be displayed. @@ -295,10 +295,10 @@ implementation of that tool. ### Pygments data -The list of languages supported by our markdown syntax highlighting +The list of languages supported by our Markdown syntax highlighting comes from the [pygments][] package. `tools/setup/build_pygments_data` is responsible for generating `static/generated/pygments_data.json` so that -our JavaScript markdown processor has access to the supported list. +our JavaScript Markdown processor has access to the supported list. ## Modifying provisioning diff --git a/docs/subsystems/emoji.md b/docs/subsystems/emoji.md index 8b5be27a59..45a644827d 100644 --- a/docs/subsystems/emoji.md +++ b/docs/subsystems/emoji.md @@ -79,7 +79,7 @@ The emoji tree generated by this process contains several import elements: * `images/emoji/*.png`: A farm of symlinks from emoji names to the `images/emoji/unicode/` tree. This is used to serve individual emoji images, as well as for the - [backend markdown processor](../subsystems/markdown.md) to know which emoji + [backend Markdown processor](../subsystems/markdown.md) to know which emoji names exist and what unicode emoji / images they map to. In this tree, we currently include all of the emoji in `emoji-map.json`; this means that if you send `:angry_face:`, it won't autocomplete, diff --git a/docs/subsystems/logging.md b/docs/subsystems/logging.md index f9ad82dba0..df42946b5f 100644 --- a/docs/subsystems/logging.md +++ b/docs/subsystems/logging.md @@ -87,7 +87,7 @@ The format of this output is: * HTTP status code * Time to process * (Optional perf data details, e.g. database time/queries, memcached -time/queries, Django process startup time, markdown processing time, +time/queries, Django process startup time, Markdown processing time, etc.) * Endpoint/URL from zproject/urls.py * "email via client" showing user account involved (if logged in) and @@ -95,7 +95,7 @@ the type of client they used ("web", "Android", etc.). The performance data details are particularly useful for investigating performance problems, since one can see at a glance whether a slow -request was caused by delays in the database, in the markdown +request was caused by delays in the database, in the Markdown processor, in memcached, or in other Python code. One useful thing to note, however, is that the database time is only diff --git a/docs/subsystems/markdown.md b/docs/subsystems/markdown.md index 36b5b76146..22c4a951ee 100644 --- a/docs/subsystems/markdown.md +++ b/docs/subsystems/markdown.md @@ -23,7 +23,7 @@ trip from the server. Those frontend renderings are only shown to the sender of a message, and they are (ideally) identical to the backend rendering. -The JavaScript markdown implementation has a function, +The JavaScript Markdown implementation has a function, `markdown.contains_backend_only_syntax`, that is used to check whether a message contains any syntax that needs to be rendered to HTML on the backend. If `markdown.contains_backend_only_syntax` returns true, the frontend simply won't @@ -46,10 +46,10 @@ The Python-Markdown implementation is tested by A shared set of fixed test data ("test fixtures") is present in `zerver/tests/fixtures/markdown_test_cases.json`, and is automatically used by both test suites; as a result, it is the preferred place to add new -tests for Zulip's markdown system. Some important notes on reading +tests for Zulip's Markdown system. Some important notes on reading this file: -* `expected_output` is the expected output for the backend markdown +* `expected_output` is the expected output for the backend Markdown processor. * When the frontend processor doesn't support a feature and it should just be rendered on the backend, we set `backend_only_rendering` to @@ -87,45 +87,45 @@ is a workaround due to lack of comments support in JSON. Revert your tests with `tools/test-js-with-node markdown` and backend tests with `tools/test-backend zerver.tests.test_markdown.MarkdownTest.test_markdown_fixtures`. -## Changing Zulip's markdown processor +## Changing Zulip's Markdown processor First, you will likely find these third-party resources helpful: -* **[Python-Markdown](https://pypi.python.org/pypi/Markdown)** is the markdown - library used by Zulip as a base to build our custom markdown syntax upon. +* **[Python-Markdown](https://pypi.python.org/pypi/Markdown)** is the Markdown + library used by Zulip as a base to build our custom Markdown syntax upon. * **[Python's XML ElementTree](https://docs.python.org/3/library/xml.etree.elementtree.html)** is the part of the Python standard library used by Python Markdown and any custom extensions to generate and modify the output HTML. -When changing Zulip's markdown syntax, you need to update several +When changing Zulip's Markdown syntax, you need to update several places: -* The backend markdown processor (`zerver/lib/markdown/__init__.py`). -* The frontend markdown processor (`static/js/markdown.js` and sometimes +* The backend Markdown processor (`zerver/lib/markdown/__init__.py`). +* The frontend Markdown processor (`static/js/markdown.js` and sometimes `static/third/marked/lib/marked.js`), or `markdown.contains_backend_only_syntax` if your changes won't be supported in the frontend processor. * If desired, the typeahead logic in `static/js/composebox_typeahead.js`. * The test suite, probably via adding entries to `zerver/tests/fixtures/markdown_test_cases.json`. -* The in-app markdown documentation (`templates/zerver/app/markdown_help.html`). -* The list of changes to markdown at the end of this document. +* The in-app Markdown documentation (`templates/zerver/app/markdown_help.html`). +* The list of changes to Markdown at the end of this document. Important considerations for any changes are: -* Security: A bug in the markdown processor can lead to XSS issues. +* Security: A bug in the Markdown processor can lead to XSS issues. For example, we should not insert unsanitized HTML from a third-party web application into a Zulip message. * Uniqueness: We want to avoid users having a bad experience due to - accidentally triggering markdown syntax or typeahead that isn't + accidentally triggering Markdown syntax or typeahead that isn't related to what they are trying to express. * Performance: Zulip can render a lot of messages very quickly, and we'd like to keep it that way. New regular expressions similar to the ones already present are unlikely to be a problem, but we need to be thoughtful about expensive computations or third-party API requests. -* Database: The backend markdown processor runs inside a Python thread +* Database: The backend Markdown processor runs inside a Python thread (as part of how we implement timeouts for third-party API queries), and for that reason we currently should avoid making database - queries inside the markdown processor. This is a technical + queries inside the Markdown processor. This is a technical implementation detail that could be changed with a few days of work, but is an important detail to know about until we do that work. * Testing: Every new feature should have both positive and negative @@ -134,7 +134,7 @@ Important considerations for any changes are: ## Per-realm features -Zulip's markdown processor's rendering supports a number of features +Zulip's Markdown processor's rendering supports a number of features that depend on realm-specific or user-specific data. For example, the realm could have [Linkifiers](https://zulip.com/help/add-a-custom-linkification-filter) @@ -146,9 +146,9 @@ 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 -markdown processor, our logic attaches these data to the Markdown +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. +individual Markdown rules can access the data from there. For non-message contexts (e.g. an organization's profile (aka the thing on the right-hand side of the login page), stream descriptions, diff --git a/docs/subsystems/sending-messages.md b/docs/subsystems/sending-messages.md index f09909eba0..f7fe1c76de 100644 --- a/docs/subsystems/sending-messages.md +++ b/docs/subsystems/sending-messages.md @@ -65,13 +65,13 @@ number of purposes: * Handling the [local echo details](#local-echo). * Handling certain client configuration options that affect messages. E.g. determining whether to send the - plaintext/markdown raw content or the rendered HTML (e.g. the + plaintext/Markdown raw content or the rendered HTML (e.g. the `apply_markdown` and `client_gravatar` features in our [events API docs](https://zulip.com/api/register-queue)). * Following our standard naming convention, input validation is done inside the `check_message` function, which is responsible for validating the user can send to the recipient, - [rendering the markdown](../subsystems/markdown.md), etc. -- + [rendering the Markdown](../subsystems/markdown.md), etc. -- basically everything that can fail due to bad user input. * The core `do_send_messages` function (which handles actually sending the message) is one of the most optimized and thus complex parts of @@ -113,10 +113,10 @@ browser, and then replace it with data from the server when it changes. Zulip aims for a near-perfect local echo experience, which requires is -why our [markdown system](../subsystems/markdown.md) requires both -an authoritative (backend) markdown implementation and a secondary -(frontend) markdown implementation, the latter used only for the local -echo feature. Read our markdown documentation for all the tricky +why our [Markdown system](../subsystems/markdown.md) requires both +an authoritative (backend) Markdown implementation and a secondary +(frontend) Markdown implementation, the latter used only for the local +echo feature. Read our Markdown documentation for all the tricky details on how that works and is tested. The rest of this section details how Zulip manages locally echoed @@ -231,13 +231,13 @@ from the target URL, and for slow websites, this could result in a significant delay in rendering the message and delivering it to other users. -* For this case, Zulip's backend markdown processor will render the +* For this case, Zulip's backend Markdown processor will render the message without including the URL embeds/previews, but it will add a deferred work item into the `embed_links` queue. * The [queue processor](../subsystems/queuing.md) for the `embed_links` queue will fetch the URLs, and then if they return -results, rerun the markdown processor and notify clients of the +results, rerun the Markdown processor and notify clients of the updated message `rendered_content`. * We reuse the `update_message` framework (used for diff --git a/docs/testing/manual-testing.md b/docs/testing/manual-testing.md index 269678d07f..9ad579d98b 100644 --- a/docs/testing/manual-testing.md +++ b/docs/testing/manual-testing.md @@ -197,7 +197,7 @@ exercise is about 30 minutes, assuming no bugs. ### Composing messages ### -We have pretty good automated tests for our markdown processor, so +We have pretty good automated tests for our Markdown processor, so manual testing is targeted more to other interactions. For composing a message, pay attention to details like what is automatically populated and where the focus is placed. @@ -224,7 +224,7 @@ populated and where the focus is placed. existing topic. - Formatting stuff - - Use the "A" icon to get markdown help. + - Use the "A" icon to get Markdown help. - Use the eyeball icon to show a preview and send from preview mode. - Toggle in and out of preview before sending a message. - Use @-mention to mention Hamlet (and send him a message). diff --git a/frontend_tests/casper_tests/04-compose.js b/frontend_tests/casper_tests/04-compose.js index cfe40f760a..71114159fb 100644 --- a/frontend_tests/casper_tests/04-compose.js +++ b/frontend_tests/casper_tests/04-compose.js @@ -222,7 +222,7 @@ casper.then(function () { casper.fill( 'form[action^="/json/messages"]', { - content: "**Markdown Preview** >> Test for markdown preview", + content: "**Markdown Preview** >> Test for Markdown preview", }, false ); @@ -235,8 +235,8 @@ casper.then(function () { casper.waitForSelectorTextChange("#preview_content", function () { casper.test.assertEquals( casper.getHTML("#preview_content"), - "

Markdown Preview >> Test for markdown preview

", - "Check markdown is previewed properly" + "

Markdown Preview >> Test for Markdown preview

", + "Check Markdown is previewed properly" ); }); }); diff --git a/frontend_tests/node_tests/compose.js b/frontend_tests/node_tests/compose.js index f0863e8bf6..102b150b0e 100644 --- a/frontend_tests/node_tests/compose.js +++ b/frontend_tests/node_tests/compose.js @@ -535,7 +535,7 @@ run_test("markdown_shortcuts", () => { compose.handle_keydown(event, $("#compose-textarea")); } - // This function cross tests the cmd/ctrl + markdown shortcuts in + // This function cross tests the cmd/ctrl + Markdown shortcuts in // Mac and Linux/Windows environments. So in short, this tests // that e.g. Cmd+B should be ignored on Linux/Windows and Ctrl+B // should be ignored on Mac. @@ -569,9 +569,9 @@ run_test("markdown_shortcuts", () => { // Default (Linux/Windows) userAgent tests: test_i_typed(false, false); - // Check all the ctrl + markdown shortcuts work correctly + // Check all the ctrl + Markdown shortcuts work correctly all_markdown_test(true, false); - // The Cmd + markdown shortcuts should do nothing on Linux/Windows + // The Cmd + Markdown shortcuts should do nothing on Linux/Windows os_specific_markdown_test(false, true); // Setting following platform to test in mac env @@ -579,9 +579,9 @@ run_test("markdown_shortcuts", () => { // Mac userAgent tests: test_i_typed(false, false); - // The ctrl + markdown shortcuts should do nothing on mac + // The ctrl + Markdown shortcuts should do nothing on mac os_specific_markdown_test(true, false); - // Check all the Cmd + markdown shortcuts work correctly + // Check all the Cmd + Markdown shortcuts work correctly all_markdown_test(false, true); // Reset userAgent diff --git a/frontend_tests/node_tests/markdown.js b/frontend_tests/node_tests/markdown.js index 94fd9fcef3..67beb54c2c 100644 --- a/frontend_tests/node_tests/markdown.js +++ b/frontend_tests/node_tests/markdown.js @@ -178,7 +178,7 @@ stream_data.add_sub(edgecase_stream_2); stream_data.add_sub(amp_stream); // Check the default behavior of fenced code blocks -// works properly before markdown is initialized. +// works properly before Markdown is initialized. run_test("fenced_block_defaults", () => { const input = "\n```\nfenced code\n```\n\nand then after\n"; const expected = diff --git a/frontend_tests/puppeteer_tests/03-compose.js b/frontend_tests/puppeteer_tests/03-compose.js index 0d5df2642f..603d96f86b 100644 --- a/frontend_tests/puppeteer_tests/03-compose.js +++ b/frontend_tests/puppeteer_tests/03-compose.js @@ -192,12 +192,12 @@ async function test_markdown_rendering(page) { "", ); await common.fill_form(page, 'form[action^="/json/messages"]', { - content: "**Markdown Preview** >> Test for markdown preview", + content: "**Markdown Preview** >> Test for Markdown preview", }); await page.click("#markdown_preview"); await page.waitForSelector("#preview_content", {visible: true}); const expected_markdown_html = - "

Markdown Preview >> Test for markdown preview

"; + "

Markdown Preview >> Test for Markdown preview

"; await page.waitForFunction(() => $("#preview_content").html() !== ""); markdown_preview_element = await page.$("#preview_content"); assert.equal( diff --git a/frontend_tests/zjsunit/index.js b/frontend_tests/zjsunit/index.js index ecab7ef6b4..15c68f688d 100644 --- a/frontend_tests/zjsunit/index.js +++ b/frontend_tests/zjsunit/index.js @@ -93,7 +93,7 @@ function short_tb(tb) { return lines.splice(0, i + 1).join("\n") + "\n(...)\n"; } -// Set up markdown comparison helper +// Set up Markdown comparison helper global.markdown_assert = require("./markdown_assert.js"); let current_file_name; diff --git a/requirements/common.in b/requirements/common.in index a911c6e3db..179e07de7e 100644 --- a/requirements/common.in +++ b/requirements/common.in @@ -14,7 +14,7 @@ dataclasses;python_version<"3.7" # Needed for rendering backend templates Jinja2 -# Needed for markdown processing +# Needed for Markdown processing Markdown importlib-metadata;python_version<"3.8" # for Markdown Pygments @@ -69,7 +69,7 @@ premailer # Needed for JWT-based auth PyJWT -# Needed for including other markdown files for user docs +# Needed for including other Markdown files for user docs markdown-include # Needed to access rabbitmq diff --git a/requirements/docs.in b/requirements/docs.in index 13a5dc633d..5974a9b09a 100644 --- a/requirements/docs.in +++ b/requirements/docs.in @@ -11,5 +11,5 @@ sphinx sphinx-rtd-theme -# Needed to build markdown docs +# Needed to build Markdown docs recommonmark diff --git a/static/js/compose.js b/static/js/compose.js index c2b76fb132..5e0a944924 100644 --- a/static/js/compose.js +++ b/static/js/compose.js @@ -37,7 +37,7 @@ exports.uploads_re = new RegExp( ); function make_uploads_relative(content) { - // Rewrite uploads in markdown links back to domain-relative form + // Rewrite uploads in Markdown links back to domain-relative form return content.replace(exports.uploads_re, "]($1)"); } @@ -857,8 +857,8 @@ exports.render_and_show_preview = function (preview_spinner, preview_content_box loading.make_indicator(spinner); } else { // For messages that don't appear to contain syntax that - // is only supported by our backend markdown processor, we - // render using the frontend markdown processor (but still + // is only supported by our backend Markdown processor, we + // render using the frontend Markdown processor (but still // render server-side to ensure the preview is accurate; // if the `markdown.contains_backend_only_syntax` logic is // wrong, users will see a brief flicker of the locally diff --git a/static/js/drafts.js b/static/js/drafts.js index 5a890a48fe..a1b548272f 100644 --- a/static/js/drafts.js +++ b/static/js/drafts.js @@ -272,7 +272,7 @@ exports.format_draft = function (draft) { markdown.apply_markdown(formatted); } catch (error) { // In the unlikely event that there is syntax in the - // draft content which our markdown processor is + // draft content which our Markdown processor is // unable to process, we delete the draft, so that the // drafts overlay can be opened without any errors. // We also report the exception to the server so that diff --git a/static/js/echo.js b/static/js/echo.js index 337e453678..e74c790cc6 100644 --- a/static/js/echo.js +++ b/static/js/echo.js @@ -232,7 +232,7 @@ exports.edit_locally = function (message, request) { message.mentioned_me_directly = request.mentioned_me_directly; message.alerted = request.alerted; } else { - // Otherwise, we markdown-render the message; this resets + // Otherwise, we Markdown-render the message; this resets // all flags, so we need to restore those flags that are // properties of how the user has interacted with the // message, and not its rendering. diff --git a/static/js/filter.js b/static/js/filter.js index 2acf93bb16..5ad76b5949 100644 --- a/static/js/filter.js +++ b/static/js/filter.js @@ -675,7 +675,7 @@ class Filter { if (this.has_operator("has") && is_local_echo) { // The has: operators can be applied locally for messages // rendered by the backend; links, attachments, and images - // are not handled properly by the local echo markdown + // are not handled properly by the local echo Markdown // processor. return false; } diff --git a/static/js/markdown.js b/static/js/markdown.js index 8c5111d613..d75b7edcb6 100644 --- a/static/js/markdown.js +++ b/static/js/markdown.js @@ -8,9 +8,9 @@ const emoji = require("../shared/js/emoji"); const fenced_code = require("../shared/js/fenced_code"); const marked = require("../third/marked/lib/marked"); -// This contains zulip's frontend markdown implementation; see +// This contains zulip's frontend Markdown implementation; see // docs/subsystems/markdown.md for docs on our Markdown syntax. The other -// main piece in rendering markdown client-side is +// main piece in rendering Markdown client-side is // static/third/marked/lib/marked.js, which we have significantly // modified from the original implementation. @@ -25,7 +25,7 @@ let helpers; const realm_filter_map = new Map(); let realm_filter_list = []; -// Regexes that match some of our common backend-only markdown syntax +// Regexes that match some of our common backend-only Markdown syntax const backend_only_markdown_re = [ // Inline image previews, check for contiguous chars ending in image suffix // To keep the below regexes simple, split them out for the end-of-message case @@ -80,7 +80,7 @@ exports.translate_emoticons_to_names = (text) => { exports.contains_backend_only_syntax = function (content) { // Try to guess whether or not a message contains syntax that only the - // backend markdown processor can correctly handle. + // backend Markdown processor can correctly handle. // If it doesn't, we can immediately render it client-side for local echo. const markedup = backend_only_markdown_re.find((re) => re.test(content)); @@ -319,7 +319,7 @@ function handleTimestamp(time) { if (isNaN(time)) { // Moment throws a large deprecation warning when it has to fallback // to the Date() constructor. We needn't worry here and can let backend - // markdown handle any dates that moment misses. + // Markdown handle any dates that moment misses. moment.suppressDeprecationWarnings = true; timeobject = moment(time); // not a Unix timestamp } else { @@ -501,7 +501,7 @@ exports.initialize = function (realm_filters, helper_config) { }; } - // Configure the marked markdown parser for our usage + // Configure the marked Markdown parser for our usage const r = new marked.Renderer(); // No around our code blocks instead a codehilite
and disable @@ -512,7 +512,7 @@ exports.initialize = function (realm_filters, helper_config) { const old_link = r.link; r.link = (href, title, text) => old_link.call(r, href, title, text.trim() ? text : href); - // Put a newline after a
in the generated HTML to match markdown + // Put a newline after a
in the generated HTML to match Markdown r.br = function () { return "
\n"; }; diff --git a/static/js/markdown_config.js b/static/js/markdown_config.js index 116b96a448..771d4613b9 100644 --- a/static/js/markdown_config.js +++ b/static/js/markdown_config.js @@ -9,11 +9,11 @@ I also wanted to make some diffs clear before doing any major file moves. - Also, I want the unit tests for markdown to + Also, I want the unit tests for Markdown to be able to reuse this code easily (and therefore didn't just put this in ui_init.js). - Once the first steps of making markdown be a + Once the first steps of making Markdown be a shared library are complete, we may tweak the file organization a bit. diff --git a/static/js/message_list_view.js b/static/js/message_list_view.js index 5fa7dadc6f..29b39942f1 100644 --- a/static/js/message_list_view.js +++ b/static/js/message_list_view.js @@ -521,7 +521,7 @@ class MessageListView { // (and is not possible to handle solely via CSS), this is // where we modify the content. It is a goal to minimize how // much logic is present in this function; wherever possible, - // we should implement features with the markdown processor, + // we should implement features with the Markdown processor, // HTML and CSS. if (row.length !== 1) { diff --git a/static/js/popovers.js b/static/js/popovers.js index 9887dfbc6c..c29d5cb7bf 100644 --- a/static/js/popovers.js +++ b/static/js/popovers.js @@ -739,7 +739,7 @@ exports.register_click_handlers = function () { $("#main_div").on("click", ".user-mention", function (e) { const id_string = $(this).attr("data-user-id"); - // We fallback to email to handle legacy markdown that was rendered + // We fallback to email to handle legacy Markdown that was rendered // before we cut over to using data-user-id const email = $(this).attr("data-user-email"); if (id_string === "*" || email === "*") { diff --git a/static/js/rendered_markdown.js b/static/js/rendered_markdown.js index 2067417220..9f08755a27 100644 --- a/static/js/rendered_markdown.js +++ b/static/js/rendered_markdown.js @@ -9,13 +9,13 @@ const moment = require("moment"); update any renamed users/streams/groups etc. and other dynamic parts of our rendered messages. - Use this module wherever some markdown rendered content + Use this module wherever some Markdown rendered content is being displayed. */ function get_user_id_for_mention_button(elem) { const user_id_string = $(elem).attr("data-user-id"); - // Handle legacy markdown that was rendered before we cut + // Handle legacy Markdown that was rendered before we cut // over to using data-user-id. const email = $(elem).attr("data-user-email"); diff --git a/static/js/spoilers.js b/static/js/spoilers.js index 96d4571756..6c258d15e8 100644 --- a/static/js/spoilers.js +++ b/static/js/spoilers.js @@ -55,7 +55,7 @@ exports.initialize = function () { const spoiler_content = $(this).siblings(".spoiler-content"); const target = $(e.target); - // Spoiler headers can contain markdown, including links. We + // Spoiler headers can contain Markdown, including links. We // return so that clicking such links will be be processed by // the browser rather than opening the header. if (target.closest("a").length > 0) { diff --git a/static/js/timerender.js b/static/js/timerender.js index 8f028ec18a..f2a513a7ea 100644 --- a/static/js/timerender.js +++ b/static/js/timerender.js @@ -170,7 +170,7 @@ exports.render_date = function (time, time_above, today) { return node; }; -// Renders the timestamp returned by the markdown syntax. +// Renders the timestamp returned by the Markdown syntax. exports.render_markdown_timestamp = function (time, text) { const hourformat = page_params.twenty_four_hour_time ? "HH:mm" : "h:mm A"; const timestring = time.format("ddd, MMM D YYYY, " + hourformat); diff --git a/static/js/util.js b/static/js/util.js index 7d09cbe779..f570d446d7 100644 --- a/static/js/util.js +++ b/static/js/util.js @@ -288,7 +288,7 @@ exports.clean_user_content_links = function (html) { // rel="opener noreferrer". This ensures that external links // never replace the Zulip webapp while also protecting // against reverse tabnapping attacks, without relying on the - // correctness of how Zulip's markdown processor generates links. + // correctness of how Zulip's Markdown processor generates links. // // Fragment links, which we intend to only open within the // Zulip webapp using our hashchange system, do not require diff --git a/static/shared/js/emoji.js b/static/shared/js/emoji.js index e4441b830f..e425cf85fe 100644 --- a/static/shared/js/emoji.js +++ b/static/shared/js/emoji.js @@ -98,7 +98,7 @@ export function get_realm_emoji_url(emoji_name) { // may have hand-typed an invalid emoji. // The caller can check the result for falsiness // and then try alternate ways of parsing the - // emoji (in the case of markdown) or just do + // emoji (in the case of Markdown) or just do // whatever makes sense for the caller. return; } diff --git a/static/styles/rendered_markdown.scss b/static/styles/rendered_markdown.scss index 291234e201..282215243b 100644 --- a/static/styles/rendered_markdown.scss +++ b/static/styles/rendered_markdown.scss @@ -78,7 +78,7 @@ border-right: 5px solid hsl(0, 0%, 87%); } - /* Formatting for markdown tables */ + /* Formatting for Markdown tables */ table { padding-right: 10px; margin: 5px 5px 5px 5px; diff --git a/templates/zerver/api/changelog.md b/templates/zerver/api/changelog.md index d549b3c880..989055056a 100644 --- a/templates/zerver/api/changelog.md +++ b/templates/zerver/api/changelog.md @@ -41,7 +41,7 @@ No changes; feature level used for Zulip 3.0 release. **Feature level 24** -* The `!avatar()` and `!gravatar()` markdown syntax, which was never +* The `!avatar()` and `!gravatar()` Markdown syntax, which was never documented, had inconsistent syntax, and was rarely used, was removed. @@ -106,7 +106,7 @@ No changes; feature level used for Zulip 3.0 release. **Feature level 15** * Added [spoilers](/help/format-your-message-using-markdown#spoilers) - to supported markdown features. + to supported Markdown features. **Feature level 14** @@ -166,7 +166,7 @@ No changes; feature level used for Zulip 3.0 release. and [`GET /users/me`](/api/get-own-user): User objects now contain the `is_owner` field as well. * Added [time mentions](/help/format-your-message-using-markdown#mention-a-time) - to supported markdown features. + to supported Markdown features. **Feature level 7** diff --git a/templates/zerver/api/get-raw-message.md b/templates/zerver/api/get-raw-message.md index f442dd182c..6a3289c1e1 100644 --- a/templates/zerver/api/get-raw-message.md +++ b/templates/zerver/api/get-raw-message.md @@ -1,4 +1,4 @@ -# Get a message's raw markdown +# Get a message's raw Markdown {generate_api_description(/messages/{message_id}:get)} diff --git a/templates/zerver/api/incoming-webhooks-overview.md b/templates/zerver/api/incoming-webhooks-overview.md index 49cb348a7f..7b9b9dad45 100644 --- a/templates/zerver/api/incoming-webhooks-overview.md +++ b/templates/zerver/api/incoming-webhooks-overview.md @@ -108,7 +108,7 @@ below are for a webhook named `MyWebHook`. ## General advice * Consider using our Zulip markup to make the output from your - integration especially attractive or useful (e.g. emoji, markdown + integration especially attractive or useful (e.g. emoji, Markdown emphasis or @-mentions). * Use topics effectively to ensure sequential messages about the same diff --git a/templates/zerver/api/outgoing-webhooks.md b/templates/zerver/api/outgoing-webhooks.md index dc2bc927d7..bd035f9644 100644 --- a/templates/zerver/api/outgoing-webhooks.md +++ b/templates/zerver/api/outgoing-webhooks.md @@ -95,7 +95,7 @@ A correctly implemented endpoint will do the following: * It will calculate a response that we call the "content" of the response. -* It will encode the content in Zulip's flavor of markdown (or +* It will encode the content in Zulip's flavor of Markdown (or just plain text). * It will then make a dictionary with key of "content" and the value being that content. (Note that "response_string" is diff --git a/templates/zerver/for-open-source.html b/templates/zerver/for-open-source.html index c1bec0e45c..d76b79a054 100644 --- a/templates/zerver/for-open-source.html +++ b/templates/zerver/for-open-source.html @@ -2,7 +2,7 @@ {% set entrypoint = "landing-page" %} {% set OPEN_GRAPH_TITLE = 'Modern chat for open source' %} -{% set OPEN_GRAPH_DESCRIPTION = 'No message limits, rich moderation features, markdown support, and a conversation model that scales to thousands of users.' %} +{% set OPEN_GRAPH_DESCRIPTION = 'No message limits, rich moderation features, Markdown support, and a conversation model that scales to thousands of users.' %} {% block title %} Zulip: the best group chat for open source projects diff --git a/templates/zerver/help/import-from-gitter.md b/templates/zerver/help/import-from-gitter.md index e70b619778..31feeab11b 100644 --- a/templates/zerver/help/import-from-gitter.md +++ b/templates/zerver/help/import-from-gitter.md @@ -109,8 +109,8 @@ to mark the appropriate users as administrators. organization using [this tool](https://github.com/minrk/archive-gitter/pull/5). -- This tool doesn't translate Gitter's markdown format into Zulip - format markdown (there are a few corner cases where the syntax is +- This tool doesn't translate Gitter's Markdown format into Zulip + format Markdown (there are a few corner cases where the syntax is different). Additionally, Gitter's [issue mentions](https://gitter.zendesk.com/hc/en-us/articles/200176692-Issue-and-Pull-Request-mentions) aren't translated into anything yet. diff --git a/templates/zerver/help/include/rest-endpoints.md b/templates/zerver/help/include/rest-endpoints.md index a0016f95a2..448b22d3b2 100644 --- a/templates/zerver/help/include/rest-endpoints.md +++ b/templates/zerver/help/include/rest-endpoints.md @@ -9,7 +9,7 @@ * [Add an emoji reaction](/api/add-reaction) * [Remove an emoji reaction](/api/remove-reaction) * [Render a message](/api/render-message) -* [Get a message's raw markdown](/api/get-raw-message) +* [Get a message's raw Markdown](/api/get-raw-message) * [Check messages match narrow](/api/check-narrow-matches) * [Get a message's edit history](/api/get-message-history) * [Update personal message flags](/api/update-message-flags) diff --git a/templates/zerver/help/message-a-stream-by-email.md b/templates/zerver/help/message-a-stream-by-email.md index c964ec6906..ae3342fc65 100644 --- a/templates/zerver/help/message-a-stream-by-email.md +++ b/templates/zerver/help/message-a-stream-by-email.md @@ -63,7 +63,7 @@ below by sending email to * **.prefer-html**: The body of an email is typically encoded using one or both of two common formats: plain text (`text/plain`) and HTML (`text/html`). Zulip supports constructing the Zulip message - content using either (converting HTML to markdown for the HTML + content using either (converting HTML to Markdown for the HTML format). By default, Zulip will prefer using the plain text version of an email over the converted HTML version if both are present. This option overrides that behavior to prefer the HTML version diff --git a/tools/build-release-tarball b/tools/build-release-tarball index c2a88ae49f..19d7cd5792 100755 --- a/tools/build-release-tarball +++ b/tools/build-release-tarball @@ -93,7 +93,7 @@ EOF ./tools/update-prod-static -# We don't need duplicate copies of emoji with hashed paths, and they would break markdown +# We don't need duplicate copies of emoji with hashed paths, and they would break Markdown find prod-static/serve/generated/emoji/images/emoji/ -regex '.*\.[0-9a-f]+\.png' -delete echo "$GITID" > build_id diff --git a/tools/check-templates b/tools/check-templates index 7e88062d90..957da59058 100755 --- a/tools/check-templates +++ b/tools/check-templates @@ -127,7 +127,7 @@ def check_html_templates(templates: Iterable[str], all_dups: bool, fix: bool) -> IGNORE_FILES = [ # zephyr-mirror.html has some whitespace-dependent formatting # for code blocks that prevent cleaning it. Might make sense - # to convert it to a /help/ markdown article. + # to convert it to a /help/ Markdown article. 'templates/corporate/zephyr-mirror.html', # Can't clean this because of `preserve_spaces` 'templates/zerver/app/markdown_help.html', diff --git a/tools/lib/capitalization.py b/tools/lib/capitalization.py index 4664cd260a..625778e54d 100644 --- a/tools/lib/capitalization.py +++ b/tools/lib/capitalization.py @@ -35,6 +35,7 @@ IGNORED_PHRASES = [ r"LDAP", r"Mac", r"macOS", + r"Markdown", r"MiB", r"OAuth", r"OTP", diff --git a/tools/linter_lib/custom_check.py b/tools/linter_lib/custom_check.py index 5fa6fb3e54..ca35feebb0 100644 --- a/tools/linter_lib/custom_check.py +++ b/tools/linter_lib/custom_check.py @@ -76,7 +76,7 @@ comma_whitespace_rule: List["Rule"] = [ 'bad_lines': ['foo(1, 2, 3)', 'foo(1, 2, 3)']}, ] markdown_whitespace_rules = list([rule for rule in whitespace_rules if rule['pattern'] != r'\s+$']) + [ - # Two spaces trailing a line with other content is okay--it's a markdown line break. + # Two spaces trailing a line with other content is okay--it's a Markdown line break. # This rule finds one space trailing a non-space, three or more trailing spaces, and # spaces on an empty line. {'pattern': r'((?[^\]]+)\]\((?P=url)\)', - 'description': 'Linkified markdown URLs should use cleaner syntax.'}, + 'description': 'Linkified Markdown URLs should use cleaner syntax.'}, {'pattern': 'https://zulip.readthedocs.io/en/latest/[a-zA-Z0-9]', 'exclude': {'docs/overview/contributing.md', 'docs/overview/readme.md', 'docs/README.md'}, 'include_only': {'docs/'}, diff --git a/tools/setup/emoji/build_emoji b/tools/setup/emoji/build_emoji index d942a0e8e7..2a5e50fa3d 100755 --- a/tools/setup/emoji/build_emoji +++ b/tools/setup/emoji/build_emoji @@ -322,7 +322,7 @@ def setup_old_emoji_farm(cache_path: str, def generate_map_files(cache_path: str, emoji_catalog: Dict[str, List[str]]) -> None: # This function generates the main data file about emoji that are - # consumed by the webapp, mobile apps, markdown processor, etc. + # consumed by the webapp, mobile apps, Markdown processor, etc. names = emoji_names_for_picker(EMOJI_NAME_MAPS) codepoint_to_name = generate_codepoint_to_name_map(EMOJI_NAME_MAPS) name_to_codepoint = generate_name_to_codepoint_map(EMOJI_NAME_MAPS) diff --git a/zerver/data_import/slack_message_conversion.py b/zerver/data_import/slack_message_conversion.py index bfd8a54eb2..837bbbd64f 100644 --- a/zerver/data_import/slack_message_conversion.py +++ b/zerver/data_import/slack_message_conversion.py @@ -128,7 +128,7 @@ def get_user_mentions(token: str, users: List[ZerverFieldsT], return token, user_id return token, None -# Map italic, bold and strikethrough markdown +# Map italic, bold and strikethrough Markdown def convert_markdown_syntax(text: str, regex: str, zulip_keyword: str) -> str: """ Returns: diff --git a/zerver/lib/actions.py b/zerver/lib/actions.py index 72af553d39..0a3411ceeb 100644 --- a/zerver/lib/actions.py +++ b/zerver/lib/actions.py @@ -1197,7 +1197,7 @@ def get_recipient_info(recipient: Recipient, message_to_user_id_set = set(message_to_user_ids) user_ids = set(message_to_user_id_set) - # Important note: Because we haven't rendered markdown yet, we + # Important note: Because we haven't rendered Markdown yet, we # don't yet know which of these possibly-mentioned users was # actually mentioned in the message (in other words, the # mention syntax might have been in a code block or otherwise @@ -1271,7 +1271,7 @@ def get_recipient_info(recipient: Recipient, # mentioned in it, and so can't use get_ids_for. # # Further in the do_send_messages code path, once - # `mentioned_user_ids` has been computed via markdown, we'll filter + # `mentioned_user_ids` has been computed via Markdown, we'll filter # these data structures for just those users who are either a # direct recipient or were mentioned; for now, we're just making # sure we have the data we need for that without extra database @@ -1676,7 +1676,7 @@ def create_user_messages(message: Message, ums_to_create.append(um) # These properties on the Message are set via - # render_markdown by code in the markdown inline patterns + # render_markdown by code in the Markdown inline patterns wildcard = message.mentions_wildcard ids_with_alert_words = message.user_ids_with_alert_words @@ -4522,7 +4522,7 @@ def do_update_message(user_profile: UserProfile, message: Message, event['is_me_message'] = Message.is_status_message(content, rendered_content) # message.has_image and message.has_link will have been - # already updated by markdown rendering in the caller. + # already updated by Markdown rendering in the caller. message.has_attachment = check_attachment_reference_change(message) if message.is_stream_message(): diff --git a/zerver/lib/email_notifications.py b/zerver/lib/email_notifications.py index 23ab74b1f8..7522056fcb 100644 --- a/zerver/lib/email_notifications.py +++ b/zerver/lib/email_notifications.py @@ -70,7 +70,7 @@ def relative_to_full_url(base_url: str, content: str) -> str: container.drop_tree() # The previous block handles most inline images, but for messages - # where the entire markdown input was just the URL of an image + # where the entire Markdown input was just the URL of an image # (i.e. the entire body is a message_inline_image object), the # entire message body will be that image element; here, we need a # more drastic edit to the content. diff --git a/zerver/lib/exceptions.py b/zerver/lib/exceptions.py index 2a6df96b08..e131ed7658 100644 --- a/zerver/lib/exceptions.py +++ b/zerver/lib/exceptions.py @@ -175,7 +175,7 @@ class InvalidMarkdownIncludeStatement(JsonableError): @staticmethod def msg_format() -> str: - return _("Invalid markdown include statement: {include_statement}") + return _("Invalid Markdown include statement: {include_statement}") class RateLimited(Exception): def __init__(self, msg: str="") -> None: diff --git a/zerver/lib/import_realm.py b/zerver/lib/import_realm.py index 3e77e3e555..85395185bb 100644 --- a/zerver/lib/import_realm.py +++ b/zerver/lib/import_realm.py @@ -259,7 +259,7 @@ def fix_message_rendered_content(realm: Realm, for message in messages: if message['rendered_content'] is not None: # For Zulip->Zulip imports, we use the original rendered - # markdown; this avoids issues where e.g. a mention can no + # Markdown; this avoids issues where e.g. a mention can no # longer render properly because a user has changed their # name. # @@ -329,11 +329,11 @@ def fix_message_rendered_content(realm: Realm, message['rendered_content_version'] = markdown_version except Exception: # This generally happens with two possible causes: - # * rendering markdown throwing an uncaught exception - # * rendering markdown failing with the exception being - # caught in markdown (which then returns None, causing the the + # * rendering Markdown throwing an uncaught exception + # * rendering Markdown failing with the exception being + # caught in Markdown (which then returns None, causing the the # rendered_content assert above to fire). - logging.warning("Error in markdown rendering for message ID %s; continuing", message['id']) + logging.warning("Error in Markdown rendering for message ID %s; continuing", message['id']) def current_table_ids(data: TableData, table: TableName) -> List[int]: """ @@ -1218,7 +1218,7 @@ def import_message_data(realm: Realm, sender_map=sender_map, messages=data['zerver_message'], ) - logging.info("Successfully rendered markdown for message batch") + logging.info("Successfully rendered Markdown for message batch") # A LOT HAPPENS HERE. # This is where we actually import the message data. diff --git a/zerver/lib/markdown/__init__.py b/zerver/lib/markdown/__init__.py index 44cf35d4bc..d9099d3814 100644 --- a/zerver/lib/markdown/__init__.py +++ b/zerver/lib/markdown/__init__.py @@ -1,5 +1,5 @@ -# Zulip's main markdown implementation. See docs/subsystems/markdown.md for -# detailed documentation on our markdown syntax. +# Zulip's main Markdown implementation. See docs/subsystems/markdown.md for +# detailed documentation on our Markdown syntax. import datetime import functools import html @@ -102,7 +102,7 @@ class LinkInfo(TypedDict): DbData = Dict[str, Any] -# Format version of the markdown rendering; stored along with rendered +# Format version of the Markdown rendering; stored along with rendered # messages so that we can efficiently determine what needs to be re-rendered version = 1 @@ -1124,7 +1124,7 @@ class InlineInterestingLinkProcessor(markdown.treeprocessors.Treeprocessor): unique_previewable_urls = {found_url.result[0] for found_url in found_urls if not found_url.family.in_blockquote} - # Set has_link and similar flags whenever a message is processed by markdown + # Set has_link and similar flags whenever a message is processed by Markdown if self.md.zulip_message: self.md.zulip_message.has_link = len(found_urls) > 0 self.md.zulip_message.has_image = False # This is updated in self.add_a @@ -2096,7 +2096,7 @@ def maybe_update_markdown_engines(realm_filters_key: Optional[int], email_gatewa if realm_filters_key not in realm_filter_data or \ realm_filter_data[realm_filters_key] != realm_filters: # Realm filters data has changed, update `realm_filter_data` and any - # of the existing markdown engines using this set of realm filters. + # of the existing Markdown engines using this set of realm filters. realm_filter_data[realm_filters_key] = realm_filters for email_gateway_flag in [True, False]: if (realm_filters_key, email_gateway_flag) in md_engines: @@ -2257,7 +2257,7 @@ def do_convert(content: str, # This logic is a bit convoluted, but the overall goal is to support a range of use cases: # * Nothing is passed in other than content -> just run default options (e.g. for docs) # * message is passed, but no realm is -> look up realm from message - # * message_realm is passed -> use that realm for markdown purposes + # * message_realm is passed -> use that realm for Markdown purposes if message is not None: if message_realm is None: message_realm = message.get_realm() @@ -2300,7 +2300,7 @@ def do_convert(content: str, _md_engine.url_embed_preview_enabled = url_embed_preview_enabled( message, message_realm, no_previews) - # Pre-fetch data from the DB that is used in the markdown thread + # Pre-fetch data from the DB that is used in the Markdown thread if message_realm is not None: # Here we fetch the data structures needed to render @@ -2332,7 +2332,7 @@ def do_convert(content: str, try: # Spend at most 5 seconds rendering; this protects the backend - # from being overloaded by bugs (e.g. markdown logic that is + # from being overloaded by bugs (e.g. Markdown logic that is # extremely inefficient in corner cases) as well as user # errors (e.g. a realm filter that makes some syntax # infinite-loop). diff --git a/zerver/lib/mdiff.py b/zerver/lib/mdiff.py index 3bde46030f..6297ac8f54 100755 --- a/zerver/lib/mdiff.py +++ b/zerver/lib/mdiff.py @@ -10,7 +10,7 @@ def diff_strings(output: str, expected_output: str) -> str: mdiff_path = "frontend_tests/zjsunit/mdiff.js" if not os.path.isfile(mdiff_path): # nocoverage - msg = "Cannot find mdiff for markdown diff rendering" + msg = "Cannot find mdiff for Markdown diff rendering" logging.error(msg) raise DiffException(msg) diff --git a/zerver/lib/message.py b/zerver/lib/message.py index dabfdb5c65..5358d6bd46 100644 --- a/zerver/lib/message.py +++ b/zerver/lib/message.py @@ -399,15 +399,15 @@ class MessageDict: if Message.need_to_render_content(rendered_content, rendered_content_version, markdown_version): # We really shouldn't be rendering objects in this method, but there is - # a scenario where we upgrade the version of markdown and fail to run + # a scenario where we upgrade the version of Markdown and fail to run # management commands to re-render historical messages, and then we # need to have side effects. This method is optimized to not need full - # blown ORM objects, but the markdown renderer is unfortunately highly + # blown ORM objects, but the Markdown renderer is unfortunately highly # coupled to Message, and we also need to persist the new rendered content. # If we don't have a message object passed in, we get one here. The cost # of going to the DB here should be overshadowed by the cost of rendering # and updating the row. - # TODO: see #1379 to eliminate markdown dependencies + # TODO: see #1379 to eliminate Markdown dependencies message = Message.objects.select_related().get(id=message_id) assert message is not None # Hint for mypy. @@ -689,7 +689,7 @@ def do_render_markdown(message: Message, realm_alert_words_automaton: Optional[ahocorasick.Automaton]=None, mention_data: Optional[MentionData]=None, email_gateway: bool=False) -> str: - """Return HTML for given markdown. Markdown may add properties to the + """Return HTML for given Markdown. Markdown may add properties to the message object such as `mentions_user_ids`, `mentions_user_group_ids`, and `mentions_wildcard`. These are only on this Django object and are not saved in the database. @@ -702,7 +702,7 @@ def do_render_markdown(message: Message, message.links_for_preview = set() message.user_ids_with_alert_words = set() - # DO MAIN WORK HERE -- call markdown to convert + # DO MAIN WORK HERE -- call markdown_convert to convert rendered_content = markdown_convert( content, realm_alert_words_automaton=realm_alert_words_automaton, diff --git a/zerver/lib/outgoing_webhook.py b/zerver/lib/outgoing_webhook.py index dc6c0aa035..e2acaed81a 100644 --- a/zerver/lib/outgoing_webhook.py +++ b/zerver/lib/outgoing_webhook.py @@ -166,7 +166,7 @@ def send_response_message(bot_id: int, message_info: Dict[str, Any], response_da topic - see get_topic_from_message_info response_data is what the bot wants to send back and has these fields: - content - raw markdown content for Zulip to render + content - raw Markdown content for Zulip to render """ message_type = message_info['type'] diff --git a/zerver/lib/send_email.py b/zerver/lib/send_email.py index c3f017b251..f28ab5b917 100644 --- a/zerver/lib/send_email.py +++ b/zerver/lib/send_email.py @@ -280,7 +280,7 @@ def send_custom_email(users: List[UserProfile], options: Dict[str, Any]) -> None subject_path = f"templates/{email_id}.subject.txt" os.makedirs(os.path.dirname(html_source_template_path), exist_ok=True) - # First, we render the markdown input file just like our + # First, we render the Markdown input file just like our # user-facing docs with render_markdown_path. with open(plain_text_template_path, "w") as f: f.write(parsed_email_template.get_payload()) diff --git a/zerver/lib/test_data.source.txt b/zerver/lib/test_data.source.txt index 7e4ab2d991..2e5c733f70 100644 --- a/zerver/lib/test_data.source.txt +++ b/zerver/lib/test_data.source.txt @@ -177,11 +177,11 @@ on technical design issues. what if you just want to look at something and go back to where you were? -As a first step, I think it is viable to show the raw markdown, and then +As a first step, I think it is viable to show the raw Markdown, and then replace it when the server sends the update event. Hmmm, I would not say the current implementation would handle all the math -and the complex markdown, but it does pass all the tests in that file +and the complex Markdown, but it does pass all the tests in that file Wait, is this from the frontend js code or backend python code diff --git a/zerver/lib/timezone.py b/zerver/lib/timezone.py index 99fe727ca2..98d6628ffa 100644 --- a/zerver/lib/timezone.py +++ b/zerver/lib/timezone.py @@ -51,7 +51,7 @@ timezone_data = None # _calculate_timezones takes about 25ms to run, so we want to cache # its results (while avoiding running it on process startup since we -# only need it for markdown rendering). +# only need it for Markdown rendering). def get_common_timezones() -> Dict[str, Union[int, Any]]: global timezone_data if timezone_data is None: diff --git a/zerver/lib/users.py b/zerver/lib/users.py index 04280b7939..b219ec7d36 100644 --- a/zerver/lib/users.py +++ b/zerver/lib/users.py @@ -41,7 +41,7 @@ def check_full_name(full_name_raw: str) -> str: character in UserProfile.NAME_INVALID_CHARS): raise JsonableError(_("Invalid characters in name!")) # Names ending with e.g. `|15` could be ambiguous for - # sloppily-written parsers of our markdown syntax for mentioning + # sloppily-written parsers of our Markdown syntax for mentioning # users with ambiguous names, and likely have no real use, so we # ban them. if re.search(r"\|\d+$", full_name_raw): diff --git a/zerver/logging_handlers.py b/zerver/logging_handlers.py index b17b58302c..bf0ca444bc 100644 --- a/zerver/logging_handlers.py +++ b/zerver/logging_handlers.py @@ -94,7 +94,7 @@ class AdminNotifyHandler(logging.Handler): # This parameter determines whether Zulip should attempt to # send Zulip messages containing the error report. If there's - # syntax that makes the markdown processor throw an exception, + # syntax that makes the Markdown processor throw an exception, # we really don't want to send that syntax into a new Zulip # message in exception handler (that's the stuff of which # recursive exception loops are made). diff --git a/zerver/management/commands/send_custom_email.py b/zerver/management/commands/send_custom_email.py index e8bb7e570e..dcf0763c31 100644 --- a/zerver/management/commands/send_custom_email.py +++ b/zerver/management/commands/send_custom_email.py @@ -12,7 +12,7 @@ class Command(ZulipBaseCommand): Useful to send a notice to all users of a realm or server. - The From and Subject headers can be provided in the body of the markdown + The From and Subject headers can be provided in the body of the Markdown document used to generate the email, or on the command line.""" def add_arguments(self, parser: ArgumentParser) -> None: @@ -22,13 +22,13 @@ class Command(ZulipBaseCommand): dest='markdown_template_path', required=True, type=str, - help='Path to a markdown-format body for the email.') + help='Path to a Markdown-format body for the email.') parser.add_argument('--subject', type=str, - help='Subject for the email. It can be declared in markdown file in headers') + help='Subject for the email. It can be declared in Markdown file in headers') parser.add_argument('--from-name', type=str, - help='From line for the email. It can be declared in markdown file in headers') + help='From line for the email. It can be declared in Markdown file in headers') parser.add_argument('--reply-to', type=str, help='Optional reply-to line for the email') diff --git a/zerver/models.py b/zerver/models.py index 2e42a684f1..bfd424fd84 100644 --- a/zerver/models.py +++ b/zerver/models.py @@ -739,7 +739,7 @@ def filter_format_validator(value: str) -> None: class RealmFilter(models.Model): """Realm-specific regular expressions to automatically linkify certain - strings inside the markdown processor. See "Custom filters" in the settings UI. + strings inside the Markdown processor. See "Custom filters" in the settings UI. """ id: int = models.AutoField(auto_created=True, primary_key=True, verbose_name='ID') realm: Realm = models.ForeignKey(Realm, on_delete=CASCADE) diff --git a/zerver/openapi/test_curl_examples.py b/zerver/openapi/test_curl_examples.py index f2e6a268c3..10a2de3b4b 100644 --- a/zerver/openapi/test_curl_examples.py +++ b/zerver/openapi/test_curl_examples.py @@ -17,7 +17,7 @@ from zerver.openapi.curl_param_value_generators import ( def test_generated_curl_examples_for_success(client: Client) -> None: authentication_line = f"{client.email}:{client.api_key}" - # A limited markdown engine that just processes the code example syntax. + # A limited Markdown engine that just processes the code example syntax. realm = get_realm("zulip") md_engine = markdown.Markdown(extensions=[markdown_extension.makeExtension( api_url=realm.uri + "/api")]) @@ -29,13 +29,13 @@ def test_generated_curl_examples_for_success(client: Client) -> None: for file_name in sorted(glob.glob("templates/zerver/api/*.md")): documentation_lines = open(file_name).readlines() for line in documentation_lines: - # A typical example from the markdown source looks like this: + # A typical example from the Markdown source looks like this: # {generate_code_example(curl, ...} if not line.startswith("{generate_code_example(curl"): continue # To do an end-to-end test on the documentation examples # that will be actually shown to users, we use the - # markdown rendering pipeline to compute the user-facing + # Markdown rendering pipeline to compute the user-facing # example, and then run that to test it. curl_command_html = md_engine.convert(line.strip()) unescaped_html = html.unescape(curl_command_html) diff --git a/zerver/openapi/zulip.yaml b/zerver/openapi/zulip.yaml index fd021d40f6..69efb4781c 100644 --- a/zerver/openapi/zulip.yaml +++ b/zerver/openapi/zulip.yaml @@ -397,7 +397,7 @@ paths: type: string description: | The `value` rendered in HTML. Will only be present for - custom profile field types that support markdown rendering. + custom profile field types that support Markdown rendering. This user-generated HTML content should be rendered using the same CSS and client-side security protections @@ -1855,7 +1855,7 @@ paths: orig_content: type: string description: | - The original markdown content of the message, before this edit. + The original Markdown content of the message, before this edit. orig_rendered_content: type: string description: | @@ -1863,7 +1863,7 @@ paths: prev_rendered_content_version: type: integer description: | - The markdown processor version number for the pre-edit message. + The Markdown processor version number for the pre-edit message. content: type: string description: | @@ -2288,7 +2288,7 @@ paths: set of configured [Linkifiers](/help/add-a-custom-linkification-filter) for the organization has changed. - Processing this event is important to doing markdown local echo + Processing this event is important to doing Markdown local echo correctly. properties: id: @@ -3106,7 +3106,7 @@ paths: description: | If `true`, message content is returned in the rendered HTML format. If `false`, message content is returned in the raw - markdown-format text that user entered. + Markdown-format text that user entered. schema: type: boolean default: true @@ -3706,7 +3706,7 @@ paths: This is a rarely-used endpoint relevant for clients that primarily work with HTML-rendered messages but might need to occasionally fetch - the message's raw markdown (e.g. for pre-filling a message-editing + the message's raw Markdown (e.g. for pre-filling a message-editing UI). parameters: - $ref: "#/components/parameters/MessageId" @@ -8043,7 +8043,7 @@ paths: data: type: string description: | - The message content, in raw markdown format (not rendered to HTML). + The message content, in raw Markdown format (not rendered to HTML). trigger: type: string description: | @@ -9175,7 +9175,7 @@ components: maps the integer ID of a custom profile field in the organization to a dictionary containing the user's data for that field. Generally the data includes just a single `value` key; for those custom profile fields - supporting markdown, a `rendered_value` key will also be present. + supporting Markdown, a `rendered_value` key will also be present. additionalProperties: type: object additionalProperties: false @@ -9191,7 +9191,7 @@ components: type: string description: | The `value` rendered in HTML. Will only be present for - custom profile field types that support markdown rendering. + custom profile field types that support Markdown rendering. This user-generated HTML content should be rendered using the same CSS and client-side security protections diff --git a/zerver/templatetags/app_filters.py b/zerver/templatetags/app_filters.py index 88e179c051..201f739b1f 100644 --- a/zerver/templatetags/app_filters.py +++ b/zerver/templatetags/app_filters.py @@ -78,9 +78,9 @@ docs_without_macros = [ def render_markdown_path(markdown_file_path: str, context: Mapping[str, Any]={}, pure_markdown: bool=False) -> str: - """Given a path to a markdown file, return the rendered html. + """Given a path to a Markdown file, return the rendered html. - Note that this assumes that any HTML in the markdown file is + Note that this assumes that any HTML in the Markdown file is trusted; it is intended to be used for documentation, not user data.""" @@ -136,7 +136,7 @@ def render_markdown_path(markdown_file_path: str, jinja = engines['Jinja2'] try: - # By default, we do both Jinja2 templating and markdown + # By default, we do both Jinja2 templating and Markdown # processing on the file, to make it easy to use both Jinja2 # context variables and markdown includes in the file. markdown_string = jinja.env.loader.get_source(jinja.env, markdown_file_path)[0] diff --git a/zerver/tests/test_markdown.py b/zerver/tests/test_markdown.py index 5a3c1039d8..85965ecc4c 100644 --- a/zerver/tests/test_markdown.py +++ b/zerver/tests/test_markdown.py @@ -922,7 +922,7 @@ class MarkdownTest(ZulipTestCase): realm = get_realm('zulip') - # Needs to mock an actual message because that's how markdown obtains the realm + # Needs to mock an actual message because that's how Markdown obtains the realm msg = Message(sender=self.example_user('hamlet')) converted = markdown_convert(":green_tick:", message_realm=realm, message=msg) realm_emoji = RealmEmoji.objects.filter(realm=realm, @@ -1046,7 +1046,7 @@ class MarkdownTest(ZulipTestCase): assert_conversion('Hello #123World', False) assert_conversion('Hello#123 World', False) assert_conversion('Hello#123World', False) - # Ideally, these should be converted, but markdown doesn't + # Ideally, these should be converted, but Markdown doesn't # handle word boundary detection in languages that don't use # whitespace for that correctly yet. assert_conversion('チケットは#123です', False) @@ -1229,7 +1229,7 @@ class MarkdownTest(ZulipTestCase): content = """Hello, everyone. Prod deployment has been completed And this is a new line - to test out how markdown convert this into something line ending split array + to test out how Markdown convert this into something line ending split array and this is a new line last""" render(msg, content) @@ -1969,7 +1969,7 @@ class MarkdownTest(ZulipTestCase): ) def test_mit_rendering(self) -> None: - """Test the markdown configs for the MIT Zephyr mirroring system; + """Test the Markdown configs for the MIT Zephyr mirroring system; verifies almost all inline patterns are disabled, but inline_interesting_links is still enabled""" msg = "**test**" diff --git a/zerver/tests/test_message_dict.py b/zerver/tests/test_message_dict.py index ea22a5031d..74149e4375 100644 --- a/zerver/tests/test_message_dict.py +++ b/zerver/tests/test_message_dict.py @@ -46,7 +46,7 @@ class MessageDictTest(ZulipTestCase): Different clients have different needs when it comes to things like generating avatar hashes or including both rendered and unrendered - markdown, so that explains the different shapes. + Markdown, so that explains the different shapes. And then the two codepaths have different performance needs. In the events codepath, we diff --git a/zerver/tests/test_templates.py b/zerver/tests/test_templates.py index cf8efcac37..efd8db5021 100644 --- a/zerver/tests/test_templates.py +++ b/zerver/tests/test_templates.py @@ -113,7 +113,7 @@ footer 'markdown_test_file': "zerver/tests/markdown/test_custom_include_extension.md", } - with self.assertRaisesRegex(InvalidMarkdownIncludeStatement, "Invalid markdown include statement"): + with self.assertRaisesRegex(InvalidMarkdownIncludeStatement, "Invalid Markdown include statement"): template.render(context) self.assertEqual(mock_print.mock_calls, [ call("Warning: could not find file templates/zerver/help/include/nonexistent-macro.md. Error: [Errno 2] No such file or directory: 'templates/zerver/help/include/nonexistent-macro.md'") diff --git a/zerver/tests/test_thumbnail.py b/zerver/tests/test_thumbnail.py index fb0983a398..967b859dda 100644 --- a/zerver/tests/test_thumbnail.py +++ b/zerver/tests/test_thumbnail.py @@ -173,7 +173,7 @@ class ThumbnailTest(ZulipTestCase): # Test full size image. # We remove the forward slash infront of the `/user_uploads/` to match - # markdown behaviour. + # Markdown behaviour. quoted_uri = urllib.parse.quote(uri[1:], safe='') result = self.client_get(f"/thumbnail?url={quoted_uri}&size=full") self.assertEqual(result.status_code, 302, result) @@ -197,7 +197,7 @@ class ThumbnailTest(ZulipTestCase): uri = json["uri"] # We remove the forward slash infront of the `/user_uploads/` to match - # markdown behaviour. + # Markdown behaviour. quoted_uri = urllib.parse.quote(uri[1:], safe='') result = self.client_get(f"/thumbnail?url={quoted_uri}&size=full") self.assertEqual(result.status_code, 302, result) diff --git a/zerver/tests/test_users.py b/zerver/tests/test_users.py index d01808d78d..2aeba1dcd8 100644 --- a/zerver/tests/test_users.py +++ b/zerver/tests/test_users.py @@ -338,7 +338,7 @@ class PermissionTest(ZulipTestCase): self.assert_json_error(result, 'Name too short!') def test_not_allowed_format(self) -> None: - # Name of format "Alice|999" breaks in markdown + # Name of format "Alice|999" breaks in Markdown new_name = 'iago|72' self.login('iago') req = dict(full_name=ujson.dumps(new_name)) @@ -346,7 +346,7 @@ class PermissionTest(ZulipTestCase): self.assert_json_error(result, 'Invalid format!') def test_allowed_format_complex(self) -> None: - # Adding characters after r'|d+' doesn't break markdown + # Adding characters after r'|d+' doesn't break Markdown new_name = 'Hello- 12iago|72k' self.login('iago') req = dict(full_name=ujson.dumps(new_name)) diff --git a/zerver/webhooks/appfollow/view.py b/zerver/webhooks/appfollow/view.py index b889bfae5e..09d9cbb0de 100644 --- a/zerver/webhooks/appfollow/view.py +++ b/zerver/webhooks/appfollow/view.py @@ -26,7 +26,7 @@ def api_appfollow_webhook(request: HttpRequest, user_profile: UserProfile, return json_success() def convert_markdown(text: str) -> str: - # Converts Slack-style markdown to Zulip format + # Converts Slack-style Markdown to Zulip format # Implemented mainly for AppFollow messages # Not ready for general use as some edge-cases not handled # Convert Bold diff --git a/zerver/webhooks/freshdesk/tests.py b/zerver/webhooks/freshdesk/tests.py index 5a45fb2636..c71b6b8449 100644 --- a/zerver/webhooks/freshdesk/tests.py +++ b/zerver/webhooks/freshdesk/tests.py @@ -95,7 +95,7 @@ Requester Bob added a {} note to \ def test_inline_image(self) -> None: """ Freshdesk sends us descriptions as HTML, so we have to make the - descriptions Zulip markdown-friendly while still doing our best to + descriptions Zulip Markdown-friendly while still doing our best to preserve links and images. """ expected_topic = "#12: Not enough ☃ guinea pigs" diff --git a/zerver/webhooks/jira/view.py b/zerver/webhooks/jira/view.py index d9d8ad5f24..a0a88fc700 100644 --- a/zerver/webhooks/jira/view.py +++ b/zerver/webhooks/jira/view.py @@ -66,7 +66,7 @@ def convert_jira_markup(content: str, realm: Realm) -> str: # In order to support both forms, we don't match a | in bare links content = re.sub(r'\[([^\|~]+?)\]', r'[\1](\1)', content) - # Full links which have a | are converted into a better markdown link + # Full links which have a | are converted into a better Markdown link full_link_re = re.compile(r'\[(?:(?P[^|~]+)\|)(?P<url>[^\]]*)\]') content = re.sub(full_link_re, r'[\g<title>](\g<url>)', content) diff --git a/zerver/webhooks/zendesk/doc.md b/zerver/webhooks/zendesk/doc.md index 368cd4534c..6c962811c4 100644 --- a/zerver/webhooks/zendesk/doc.md +++ b/zerver/webhooks/zendesk/doc.md @@ -45,7 +45,7 @@ the following conditions** select **Ticket: is...** and then select **Notification: Notify target**, then select **Zulip**. Next we need need to enter the message body into Message. You can use -Zulip markdown and the Zendesk placeholders when creating your message. +Zulip Markdown and the Zendesk placeholders when creating your message. You can copy this example template: diff --git a/zproject/prod_settings_template.py b/zproject/prod_settings_template.py index 220d3d97c7..7e83fadc6b 100644 --- a/zproject/prod_settings_template.py +++ b/zproject/prod_settings_template.py @@ -445,7 +445,7 @@ ENABLE_GRAVATAR = True #REMOTE_POSTGRES_SSLMODE = 'require' # If you want to set a Terms of Service for your server, set the path -# to your markdown file, and uncomment the following line. +# to your Markdown file, and uncomment the following line. #TERMS_OF_SERVICE = '/etc/zulip/terms.md' # Similarly if you want to set a Privacy Policy. diff --git a/zproject/terms.md.template b/zproject/terms.md.template index 1b98ccf1b8..08a684e944 100644 --- a/zproject/terms.md.template +++ b/zproject/terms.md.template @@ -4,4 +4,4 @@ put your terms here -* you can use markdown +* you can use Markdown