mity / md4c

C Markdown parser. Fast. SAX-like interface. Compliant to CommonMark specification.
MIT License
759 stars 140 forks source link

can't tell the difference between indented code blocks and different fences #81

Closed ec1oud closed 5 years ago

ec1oud commented 5 years ago

For Qt QTextMarkdownWriter to be able to rewrite markdown that QTextMarkdownImporter has read, it might be nice to tell the difference between indented code blocks and different types of fences. So far I've been turning all code blocks into indented ones, but perhaps fencing by default is better, because that way the language can be specified; or, perhaps fence it if the language is known, indent it if not?

But also, the fence character could be tilde or backtick. Even lower priority for Qt would be to remember which one was used, and write it back that way. So maybe MD_BLOCK_CODE_DETAIL could have MD_CHAR fence_char, and if it is left null (or a space?), that means the block was indented? Just an idea.

mity commented 5 years ago

Well, I'm not sure how far you want or to what degree it is feasible to go in such 1:1 mapping. Consider e.g. thematic rules (***** or * * * or --- or - - - or ... etc.), or all the possibilities how links can be written.

That said, adding it the MD_BLOCK_CODE_DETAIL::fence_char is definitely possible and I have nothing against it.

mity commented 5 years ago

Done.

ec1oud commented 5 years ago

Thanks. It wasn't even so urgent, just something I thought of. Also, good point that there are other cases, and not all of them are worth doing something about. In the writer I use "- - -" for thematic breaks (horizontal rules), regardless how they were read, because I figured that way it will be impossible to accidentally create a heading (if for example I wrote "---" instead, and just above happened to be a word with 3 characters).

Another such case: in markdown, underscores can be used for emphasis instead of stars; and coincidentally, Qt can render text either italicized or underlined. So technically it would be possible to "extend" markdown to support underlining by distinguishing the two kinds of emphasis, if the detail struct would tell me which character was used there. Is that evil? ;-) It goes beyond the spec, and I'm not particularly fond of underlining text, either. But I wouldn't be surprised if somebody who is fond of it eventually gets surprised that they can use a wysiwyg editor (like the textedit example) to underline something, and it will be saved with underscores; but when they read it back, the underlining gets transformed to italics, and then the next time they save it, it has stars instead of underscores.

mity commented 5 years ago

It wasn't even so urgent, just something I thought of.

I just wanted to look how much work it would be. And it turned out to be so trivial that there was no reason for any delay... Actually most of the work was the changelog record.

Is that evil? ;-)

Yes, it is horrible sin. But the world is likely full of bigger evils then that, I guess ;-)

But seriously: It should be easy to implement it too. It might be little more work only because as far as I can remember there is no detail structure at all yet for the emphasis spans, but I believe MD4C knows what character is there in the place where it calls the callback so it would be few-liner too.

Just maybe if you have list of such things, it would easier to do them in one rin instead of one by one...

Waqar144 commented 4 years ago

Hi, Thank you for such an amazing library. It is quite a work of art.

I am currently in process of migrating QOwnNotes to MD4C. We were using hoedown before and it had a flag for turning underline on or off. While I am not fond of underlines myself (except when reading books ;) ), it is a feature we were supporting before, and would like to support with MD4C as well. So, it would be great if you could add that.

mity commented 4 years ago

For a new feature suggestion, open please a new issue rather then reusing some old and/or unrelated one. Also include some description or some pointer to documentation of the requested feature. I do not use hoedown and I don't know its syntax extensions.