View Issue Details

IDProjectCategoryView StatusLast Update
0022344mantisbtmarkdownpublic2024-03-27 20:20
Reporterj_schultz Assigned Tojoel  
PrioritynormalSeverityminorReproducibilityalways
Status confirmedResolutionopen 
Product Version2.1.0 
Summary0022344: Markdown mismatches code start/end
Description

Compare against e.g. GitHub markdown, which renders this more sensibly:

Steps To Reproduce

This is the entered markup:

  1. 
    Some

Code

2. 

Some

Code

3.

Some
Code

4.

Some
Code

5.

More

Code


And here is some more text
Tagsupstream

Relationships

child of 0022180 new Markdown issues following implementation in 0017920 

Activities

joel

joel

2017-02-19 12:50

developer   ~0055720

PR: https://github.com/mantisbt/mantisbt/pull/1033

atnz

atnz

2017-02-23 01:26

reporter   ~0055753

Is markdown compatible with WYSIWYG?, can we (PLEASE) have WYSIWYG.

joel

joel

2017-02-27 18:52

developer   ~0055813

Last edited: 2017-02-27 19:04

This is a bug in upstream https://github.com/erusev/parsedown/issues/477

j_schultz

j_schultz

2018-06-06 16:28

reporter   ~0060019

The upstream issue seems to have been resolved in March, what's the status on this?

atrol

atrol

2018-06-06 16:33

developer   ~0060020

The upstream issue seems to have been resolved in March

It isn't resolved.
It's marked as duplicate of the non resolved https://github.com/erusev/parsedown/issues/466

j_schultz

j_schultz

2018-06-06 16:36

reporter   ~0060021

Sorry, it seems like I just skimmed the related issue and somehow my eyes caught the "closed" status of the 477 as being the closed status of 466. it is indeed not resolved...

dregad

dregad

2021-03-08 10:08

developer   ~0065204

This is a bug in upstream

Problem still exists, now tracked under https://github.com/erusev/parsedown/issues/477

hotzeplotz

hotzeplotz

2024-03-27 17:48

reporter   ~0068725

Now under https://github.com/erusev/parsedown/issues/707

Sample from https://github.com/erusev/parsedown/issues/466

If the code block is indented, it’s rendered correctly

1. foobar
    \``` < Ignore the "\" escape sign, seems to be a bug that it is visible
    class IInterface:
        def show(self): raise NotImplementedError
    \```
2. foobar
  1. foobar
    class IInterface:
        def show(self): raise NotImplementedError
  2. foobar

https://parsedown.org/demo

markdown-issue-codeblock.png (35,548 bytes)   
markdown-issue-codeblock.png (35,548 bytes)   
hotzeplotz

hotzeplotz

2024-03-27 17:53

reporter   ~0068726

Last edited: 2024-03-27 18:03

If this could be placed as a hint somewhere when entering texts. It might be helpful.

… wait … the \ isn’t a escape sign :-) … in all situations

hotzeplotz

hotzeplotz

2024-03-27 18:15

reporter   ~0068727

Does it make sense to keep such upstream tickets open? The Mantis team can't or won't fix them, so such bugs could be closed with a reference to the upstream issue (if exist)?

atrol

atrol

2024-03-27 20:13

developer   ~0068731

I suspect that most of the MantisBT users are interested to know in which MantisBT version a bug is fixed.
They don't want or need to know, if the root cause is in MantisBT source code or the source code of a used component.

A solution for a problem caused by an external component could also be a replacement of the component by another one.

Or let's assume that the issue will be fixed in a future version of a used component.
If we close now, most of our users would not get any notification when it's fixed in MantisBT, as they hardly watch all used components.

Other users might just watch our release announcements, have a deeper look at our change log, and decide after that if they want to upgrade.
They would not get the right list of fixes, if we close issues that are caused by external components.

hotzeplotz

hotzeplotz

2024-03-27 20:20

reporter   ~0068732

Makes sense. Thanks.