Rendering of the < character

[fliiiix]

$ cat foo.md 
foo <asdf-qwerty>bar</asdf-qwerty> and <a_b>baz</a_b>
$ markdown foo.md
<p>foo &lt;asdf-qwerty>bar&lt;/asdf-qwerty> and &lt;a_b>baz&lt;/a_b></p>

What is happening here? https://daringfireball.net/projects/markdown/dingus renders this as expected

<p>foo <asdf-qwerty>bar</asdf-qwerty> and <a_b>baz</a_b></p>

On the latests tag

markdown --version
markdown: discount ((HEAD)2.2.7b

[Orc]

That's a markdown (mis)feature you have to enable with the 1.0 flag; I turn it off by default to shrink vulnerability to script injection attacks.

[fliiiix]

MARKDOWN_FLAGS=0x00002000 markdown foo.md 
<p>foo &lt;asdf-qwerty>bar&lt;/asdf-qwerty> and &lt;a_b>baz&lt;/a_b></p>

MARKDOWN_FLAGS=0x22004 markdown foo.md 
<p>foo &lt;asdf-qwerty>bar&lt;/asdf-qwerty> and &lt;a_b>baz&lt;/a_b></p>

markdown -f1.0 foo.md 
<p>foo &lt;asdf-qwerty>bar&lt;/asdf-qwerty> and &lt;a_b>baz&lt;/a_b></p>

I wasn't able to get that even with enabling MKD_1_COMPAT mode.

Also i would like to point out that it feels very arbitrary what is treated as a markdown feature and what is different from the specs.
Based on your comment here https://github.com/Orc/discount/issues/260#issuecomment-1257270210

That's how it's supposed to work: the daringfireball dingus renders it in exactly the same way.

I would have expected the library to behave without flags compliant to the markdown spec.

(Also im sorry that i am so annoying :upside_down_face:, I am trying to understand discount to do an ok job on updating rdiscount)

[Orc]

Hmm. I didn't think I'd changed the way bogus tags were rendered since the last released, but apparently I did.

Let me reopen this bug and check it out.

[Orc]

Uuuuugh. I pulled a clean 2.2.7b, spotlessed it and built it from scratch and it's not working like you described!!!

What is your build environment?

[fliiiix]

Im on a Fedora release 36 (Thirty Six).

cc --version
cc (GCC) 12.2.1 20220819 (Red Hat 12.2.1-2)

[fliiiix]

[❤ l33tname@fedora:~] markdown -VV
markdown: discount 1.5.8
[❤ l33tname@fedora:~] markdown -f1.0 foo.md 
<p>foo &lt;asdf-qwerty>bar&lt;/asdf-qwerty> and &lt;a<em>b>baz&lt;/a</em>b></p>

Either it never worked or it needs different flags :eyes:

[Orc]

let me spin up a vm with fedora 36 and see if I can reproduce it there. I noted that behavior in 2012 and put a patch in to match markdown.pl at that time, so I'm not sure just why that data path isn't being followed on my mac box :-(

[fliiiix]

Did you have a look at my MR? From looking at the code im not sure why this ever could have worked

[Orc]

Yes I did. Apparently I never put in turning off '<' sanitation but just thought I did. 10 years ago, sigh.

Markdown.pl's behavior for bizarre '' sequences is weird. I'm trying to figure out (without looking at the source; I don't know how gruber would feel about my having markdown.pl open as a reference when chasing compatibility) what the classification patterns are for what gets a '<' and what gets a '<' and it's moderately slow going.

[Orc]

Okay, head of branch (v2.2.7c now) has been patched to conform to Markdown.pl's behavior with the -fstrict option set. Try it now and see what other things fail :-)

[fliiiix]

Will do its on my todo list i hope i find some time on the weekend

[fliiiix]

I had a look at v2.2.7c and I couldn't find any other issues.

One small thing i noticed (but this is not new with v2.2.7c) you might want look into:

main.c: In function ‘main’:
main.c:311:36: warning: passing argument 2 of ‘mkd_e_code_format’ from incompatible pointer type [-Wincompatible-pointer-types]
  311 |             mkd_e_code_format(doc, external_codefmt);
      |                                    ^~~~~~~~~~~~~~~~
      |                                    |
      |                                    char * (*)(char *, int,  char *)
In file included from main.c:12:
./mkdio.h:71:31: note: expected ‘mkd_callback_t’ {aka ‘char * (*)(const char *, const int,  void *)’} but argument is of type ‘char * (*)(char *, int,  char *)’
   71 | void mkd_e_code_format(void*, mkd_callback_t);
      |       

[fliiiix]

will you create a tag and a release for 2.2.7c?