-
Notifications
You must be signed in to change notification settings - Fork 24
Allow markdown in message format #740
Allow markdown in message format #740
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #740 +/- ##
==========================================
- Coverage 89.95% 89.94% -0.01%
==========================================
Files 83 83
Lines 14598 14678 +80
==========================================
+ Hits 13131 13202 +71
- Misses 1467 1476 +9
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
43d6440
to
b7b5ba5
Compare
Kudos, SonarCloud Quality Gate passed! |
@@ -669,8 +669,9 @@ where | |||
&self, | |||
buffer: &mut S, | |||
options: &MarkdownOptions, | |||
as_message: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be done later, but maybe it makes more sense to use a context enum for this to make it clearer what the options are. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think that's a fair point, although perhaps that would make sense to do that work if/when the number of formats that could be output extends past two?
This work brings the markdown output in line with html output and allows the client to get markdown either for the composer (in which case it will keep mentions as html) or for a message (in which case it will format the mentions as it currently does). I believe that the changes will also help us to unbreak the iOS implementation of mentions in plain text mode.
This PR:
get_content_as_message_markdown
as_message
argument through calls to functions that render the model as markdown