backslash with square bracket oddities
-
In the Notepad++ Community NodeBB instance, we are often talking about regular expressions, where you often have to backslash-encode specific characters, including square brackets.
For most escapes, just having the regex inside single-backticks , like
A\(B\)C, will allow communicating the regex, and the backticks prevent NodeBB from collapsing the escape. And similarly for longer code blocks in ``` or ~~~ blocks.However, NodeBB seems to treat backslash-left-square-bracket \[ and backslash-right-square-bracket \] as special cases, even when inside single-backticks or code blocks, and you have to go through mental gymnastics to find the right number of brackets to use. Even worse, the PREVIEW window shows what you expect would be required, but when you then submit it, extra backslashes are removed.
And further, when you try to edit a post after you've successfully gotten the number of backslashes just right for a given square bracket, then the editor shows the number of backslashes that it rendered rather than were originally typed, and when you submit after editing, NodeBB reduces the number of backslashes, thus messing up a section that used to be right.
We have a FAQ section that explains the oddities with backslash-bracket, but new users don't read FAQs and regular users forget just how strangely this special case behaves.
Examples of the rendering:
backslash count raw in backticks raw in backticks 0 ] ][ [1 ] \][ \[2 \] \\]\[ \\[3 \] \\\]\[ \\\[4 \\] \\\\]\\[ \\\\[The preview of that showed the following, where the number of backslashes in the backtick-text renders as the same number in the PREVIEW window:
Since I already made the screenshots for the FAQ in the Notepad++ forum, the screenshot I am showing is from a light theme rather than a dark theme, but the rendering of the Markdown is the same here as it is there.But that's not how it rendered once it was actually submitted/posted, which actually showed up with missing backslashes:
Similar happens in code-text-blocks
0 | ] | [ 1 | \] | \[ 2 | \\] | \\[ 3 | \\\] | \\\[ 4 | \\\\] | \\\\[Where the preview shows it correct:
... but as you can see from the render above, some of backslashes disappear.Regarding the "edit" anomaly: I will also reply to this post with the same table and codeblock examples, then edit that reply exactly once without changing anything in those sections, so you can see how it changed even when i didn't change any of the backslash-bracket text.
-
This reply
will behas been edited, but Iwon'tdidn't change anything beyond the horizontal line:
Examples of the rendering:
backslash count raw in backticks raw in backticks 0 ] ][ [1 ] ][ [2 ] \][ \[3 \] \\]\[ \\[4 \] \\\]\[ \\\[Similar happens in code-text-blocks
0 | ] | [ 1 | ] | [ 2 | \] | \[ 3 | \\] | \\[ 4 | \\\] | \\\[ -
@PeterJones thanks for reporting, this is caused by the translation module and how it escapes/unescapes content.
Strings like
[[global:posts]]are treated as translation keys but we don't want these to be translated when they are used in post content. So there is some code to escape them, render the page and then unescape it. But this code also causes the problem you are seeing. -
table
backslash count raw in backticks raw in backticks 0 ] ][ [1 ] \][ \[2 \] \\]\[ \\[3 \] \\\]\[ \\\[4 \\] \\\\]\\[ \\\\[text block
0 | ] | [ 1 | \] | \[ 2 | \\] | \\[ 3 | \\\] | \\\[ 4 | \\\\] | \\\\[... It looked good when I posted the first time; I am now editing it.
... and even after editing, it looks good.
Yes, it appears the fix works.
