mirror of
https://github.com/zulip/zulip.git
synced 2025-11-19 14:08:23 +00:00
Fix style, formatting in Bugdown docs.
This commit is contained in:
committed by
Tim Abbott
parent
ad644afa97
commit
86f7695b8c
@@ -1,28 +1,29 @@
|
|||||||
# Zulip's markdown implementation
|
# Zulip's Markdown implementation
|
||||||
|
|
||||||
Zulip has a special flavor of Markdown, currently called 'bugdown'
|
Zulip has a special flavor of Markdown, currently called 'bugdown'
|
||||||
after Zulip's original name of "humbug".
|
after Zulip's original name of "humbug". End users are using Bugdown
|
||||||
|
within the client, not original Markdown.
|
||||||
|
|
||||||
Zulip has two implementations of Bugdown. The first is based on
|
Zulip has two implementations of Bugdown. The first is based on
|
||||||
Python-Markdown (`zerver/lib/bugdown/`) and is used to authoritatively
|
Python-Markdown (`zerver/lib/bugdown/`) and is used to authoritatively
|
||||||
render messages on the backend (and implements expensive features like
|
render messages on the backend (and implements expensive features like
|
||||||
querying the Twitter API to render tweets nicely). The other is in
|
querying the Twitter API to render tweets nicely). The other is in
|
||||||
javascript, based on marked (`static/js/echo.js`), and is used to
|
JavaScript, based on marked (`static/js/echo.js`), and is used to
|
||||||
preview and locally echo messages the moment the sender hits enter,
|
preview and locally echo messages the moment the sender hits enter,
|
||||||
without waiting for round trip from the server. The two
|
without waiting for round trip from the server. The two
|
||||||
implementations are tested for compatibility via
|
implementations are tested for compatibility via
|
||||||
`zerver/tests/test_bugdown.py` and the fixtures under
|
`zerver/tests/test_bugdown.py` and the fixtures under
|
||||||
`zerver/fixtures/bugdown-data.json`.
|
`zerver/fixtures/bugdown-data.json`.
|
||||||
|
|
||||||
The javascript implementation knows which types of messages it can
|
The JavaScript implementation knows which types of messages it can
|
||||||
render correctly, and thus while there is code to rerender messages
|
render correctly, and thus while there is code to rerender messages
|
||||||
based on the authoritative backend rendering (which would clause a
|
based on the authoritative backend rendering (which would clause a
|
||||||
change in the rendering visible only to the sender shortly after a
|
change in the rendering visible only to the sender shortly after a
|
||||||
message is sent), this should never happen and whenever it does it is
|
message is sent), this should never happen, and whenever it does it is
|
||||||
considered a bug. Instead, if the frontend doesn't know how to
|
considered a bug. Instead, if the frontend doesn't know how to
|
||||||
correctly render a message, we simply won't echo the message for the
|
correctly render a message, we simply won't echo the message for the
|
||||||
sender until it's rendered by the backend. So for example, a message
|
sender until it's rendered by the backend. So for example, a message
|
||||||
containing a link to Twitter will not be rendered by the javascript
|
containing a link to Twitter will not be rendered by the JavaScript
|
||||||
implementation because it doesn't support doing the 3rd party API
|
implementation because it doesn't support doing the 3rd party API
|
||||||
queries required to render tweets nicely.
|
queries required to render tweets nicely.
|
||||||
|
|
||||||
|
|||||||
@@ -14,8 +14,8 @@ General Process
|
|||||||
Adding a field to the database
|
Adding a field to the database
|
||||||
------------------------------
|
------------------------------
|
||||||
|
|
||||||
**Update the model:** The server accesses the underlying database in `zerver/
|
**Update the model:** The server accesses the underlying database in ``zerver/
|
||||||
models.py`. Add a new field in the appropriate class.
|
models.py``. Add a new field in the appropriate class.
|
||||||
|
|
||||||
**Create and run the migration:** To create and apply a migration, run: ::
|
**Create and run the migration:** To create and apply a migration, run: ::
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user