Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
Post History
Only the list page previews need fixing I have explained the underlying causes in another answer. This answer proposes a general solution for all communities. There will rarely be a problem in a ...
Answer
#2: Post edited
by
trichoplax
·
2025-03-15T16:11:53Z (1 day ago)
Change wording to conditional since the behaviour described is not yet in place
- ## Only the list page previews need fixing
- I have explained [the underlying causes]() in another answer. This answer proposes a general solution for all communities.
- There will rarely be a problem in a post. For all of the Codidact communities that have MathJax enabled, nearly all usages of escaped square brackets and escaped parentheses will be either inside code blocks (where MathJax is not rendered) or inside intended MathJax. The only reason that the example question is rendered incorrectly in preview is that code blocks are suppressed in post previews (for example, on the question list page, search results, or the questions listed on a tag page).
- ### Allow Markdown and codeblocks in post previews
- If the regex in the example question is allowed to be rendered as a code block in the post preview then the escaped square brackets will not trigger MathJax rendering.
- ### Truncate post previews by height rather than character count
- Currently a post preview is limited to a certain number of characters.
- Allowing Markdown and code blocks in post previews could cause incorrect rendering in cases where the limited number of characters in the preview results in a section of Markdown formatting being opened but not being closed. For example, if the opening and closing asterisks of a bold section are both included, the preview would correctly show bold:
- ```text
- A preview of a post with **some bold text**.
- ```
is rendered as:- > A preview of a post with **some bold text**.
- However,
- ```text
- A preview of a post with **some bold t...
- ```
is rendered as:- > A preview of a post with **some bold t...
- The opening `**` is rendered as raw text because it lacks a closing `**`.
- This could be completely avoided by including the full text of the post and displaying only the first few lines. Alternatively, this could be mostly avoided by including a limited section of the full text and displaying only the first few lines. This second option is a compromise between including all of the text (which ensures the closing symbol is always included for each opening symbol) and keeping the network request size of the list page small. The more text is provided, the lower the probability of an opening symbol being included in the visible section for which the corresponding closing symbol is not included in the provided text.
- ## Only the list page previews need fixing
- I have explained [the underlying causes]() in another answer. This answer proposes a general solution for all communities.
- There will rarely be a problem in a post. For all of the Codidact communities that have MathJax enabled, nearly all usages of escaped square brackets and escaped parentheses will be either inside code blocks (where MathJax is not rendered) or inside intended MathJax. The only reason that the example question is rendered incorrectly in preview is that code blocks are suppressed in post previews (for example, on the question list page, search results, or the questions listed on a tag page).
- ### Allow Markdown and codeblocks in post previews
- If the regex in the example question is allowed to be rendered as a code block in the post preview then the escaped square brackets will not trigger MathJax rendering.
- ### Truncate post previews by height rather than character count
- Currently a post preview is limited to a certain number of characters.
- Allowing Markdown and code blocks in post previews could cause incorrect rendering in cases where the limited number of characters in the preview results in a section of Markdown formatting being opened but not being closed. For example, if the opening and closing asterisks of a bold section are both included, the preview would correctly show bold:
- ```text
- A preview of a post with **some bold text**.
- ```
- would be rendered as:
- > A preview of a post with **some bold text**.
- However,
- ```text
- A preview of a post with **some bold t...
- ```
- would be rendered as:
- > A preview of a post with **some bold t...
- The opening `**` is rendered as raw text because it lacks a closing `**`.
- This could be completely avoided by including the full text of the post and displaying only the first few lines. Alternatively, this could be mostly avoided by including a limited section of the full text and displaying only the first few lines. This second option is a compromise between including all of the text (which ensures the closing symbol is always included for each opening symbol) and keeping the network request size of the list page small. The more text is provided, the lower the probability of an opening symbol being included in the visible section for which the corresponding closing symbol is not included in the provided text.
#1: Initial revision
by
trichoplax
·
2025-03-15T16:07:27Z (1 day ago)
## Only the list page previews need fixing I have explained [the underlying causes]() in another answer. This answer proposes a general solution for all communities. There will rarely be a problem in a post. For all of the Codidact communities that have MathJax enabled, nearly all usages of escaped square brackets and escaped parentheses will be either inside code blocks (where MathJax is not rendered) or inside intended MathJax. The only reason that the example question is rendered incorrectly in preview is that code blocks are suppressed in post previews (for example, on the question list page, search results, or the questions listed on a tag page). ### Allow Markdown and codeblocks in post previews If the regex in the example question is allowed to be rendered as a code block in the post preview then the escaped square brackets will not trigger MathJax rendering. ### Truncate post previews by height rather than character count Currently a post preview is limited to a certain number of characters. Allowing Markdown and code blocks in post previews could cause incorrect rendering in cases where the limited number of characters in the preview results in a section of Markdown formatting being opened but not being closed. For example, if the opening and closing asterisks of a bold section are both included, the preview would correctly show bold: ```text A preview of a post with **some bold text**. ``` is rendered as: > A preview of a post with **some bold text**. However, ```text A preview of a post with **some bold t... ``` is rendered as: > A preview of a post with **some bold t... The opening `**` is rendered as raw text because it lacks a closing `**`. This could be completely avoided by including the full text of the post and displaying only the first few lines. Alternatively, this could be mostly avoided by including a limited section of the full text and displaying only the first few lines. This second option is a compromise between including all of the text (which ensures the closing symbol is always included for each opening symbol) and keeping the network request size of the list page small. The more text is provided, the lower the probability of an opening symbol being included in the visible section for which the corresponding closing symbol is not included in the provided text.