Show source after "Couldn't render historic post" #330
Comments
|
I agree that raw source should be displayed in such a case.
I think it's a not good idea to omit errors or e.g. to try removing the very notion of error from markup language as Markdown does. It results that unintended behavior is introduced all the time without users noticing. This is where RST and Markdown are different: RST is restrictive and Markdown is extremely lax. There are debatable edge cases e.g. this: nim-lang/Nim#19607. Here normal-looking doc comment There is also related proposal nim doc/rst2html output should show parsing warnings in generated html. |
|
btw, until something like this is solved (I suspect that already deploying a forum with updated nim would reduce the number of non renderable posts), a workaround to know the content of a "non renderable" post is to take advantage of nimforum api, for example: https://forum.nim-lang.org/post.rst?id=57035 shows the source of the post that opens this thread: https://forum.nim-lang.org/t/8754 more example on non renderable posts can be found searching for |
|
thanks @pietroppeter , that was what I needed to know to fix such problems, but was afraid to ask :-) |
|
Ah nice to know that it helps! 😀 And thanks a lot for the great work you are doing for the rst/md renderer (and I guess other stuff but I have noticed that)! |
Additions to RST simple tables (nim-lang#19859) made their parsing more restrictive, which can introduce problems with of some old nimforum posts, which have tables with sloppily aligned columns (like this one: nim-lang/nimforum#330 (comment)). Also this strictness contradicts to Markdown style of not getting in the way (ignoring errors). So this PR proposes a new strategy of dealing with errors: * In Markdown and legacy (old default) RstMarkdown we try to continue parsing, emitting only warnings * And only in pure RST mode we throw a error I expect that this strategy will be applied to more parts of markup code in the future.
…22165) * Don't throw errors on RST tables in Markdown and RstMarkdown modes Additions to RST simple tables (#19859) made their parsing more restrictive, which can introduce problems with of some old nimforum posts, which have tables with sloppily aligned columns (like this one: nim-lang/nimforum#330 (comment)). Also this strictness contradicts to Markdown style of not getting in the way (ignoring errors). So this PR proposes a new strategy of dealing with errors: * In Markdown and legacy (old default) RstMarkdown we try to continue parsing, emitting only warnings * And only in pure RST mode we throw a error I expect that this strategy will be applied to more parts of markup code in the future. * Don't return anything in `checkColumns`
…im-lang#22165) * Don't throw errors on RST tables in Markdown and RstMarkdown modes Additions to RST simple tables (nim-lang#19859) made their parsing more restrictive, which can introduce problems with of some old nimforum posts, which have tables with sloppily aligned columns (like this one: nim-lang/nimforum#330 (comment)). Also this strictness contradicts to Markdown style of not getting in the way (ignoring errors). So this PR proposes a new strategy of dealing with errors: * In Markdown and legacy (old default) RstMarkdown we try to continue parsing, emitting only warnings * And only in pure RST mode we throw a error I expect that this strategy will be applied to more parts of markup code in the future. * Don't return anything in `checkColumns`
|
This is fixed by the new forum instance |
Right now the "Couldn't render historic post" message obscures an entire message. This is an issue because it generally happens with really long messages. To mitigate this, the raw source should be shown instead of rendering.
Also, why is a markup format giving errors?
The text was updated successfully, but these errors were encountered: