On Mar 11, 2017, at 7:07 AM, Mark Janssen <mpc.jans...@gmail.com> wrote:
>
> the fossil markdown support is fairly limited (for example there are no code
> blocks)
We must have different definitions of “code block.”
This is a Fossil wiki page with a very large code block down at the end:
https://tangentsoft.com/pidp8i/wiki?name=PEP001.PA
And it’s an interesting programming story besides, IMHO. :)
That code block — the amber-on-black box — is simply the boxed text you see
indented four spaces, the same as specified by CommonMark.
Fossil also allows <pre> and <code> in Markdown, if you want more control over
what you get in the HTML output.
Fossil *doesn’t* support this “fenced code block” feature I see in CommonMark.
Is that what you wanted? I assume that has value for some indenting or quoting
reason, but I have yet to find the older indented code block style unsuitable.
A related wish that comes up here now and then is some kind of pretty-printer
support, so that common programming languages are colored nicely. Google’s
code-prettify JS library would work for this:
https://github.com/google/code-prettify
I have found bugs in Fossil’s Markdown implementation. For example, it doesn’t
deal properly with hyperlinks to Wikipedia documents that end in a parenthesis,
as when the Wikipedia topic needs disambiguation:
I like [Fossil](https://en.wikipedia.org/wiki/Fossil_(software))!
The URL is missing the trailing closing paren and an extra closing paren shows
up in the HTML rendered output.
It would also be nice to have Markdown support in tickets. I write Markdown
text faster than I write Wiki formatted text.
> I have made a version of fossil which supports the commonmark markdown format
If it’s simply “stronger” than the current Markdown implementation on the
common subset of the two Markdown flavors, I’m in favor of the change. I don’t
mind going back and tweaking my Markdown text to format correctly under the new
system, especially if the differences amount to removing workarounds for
Fossil’s current Markdown rendering engine.
> - (Maybe) add a repo wide markdown flavour setting
That sounds necessary, at least through the transition period, for much the
same reason we how have “fossil set hash-policy”.
If I update my local Fossil with your version and say “fossil ui” in a repo
made by someone who doesn’t use a Fossil binary with your Markdown engine, the
Markdown might not render properly if my Fossil doesn’t also know how to use
the “legacy” rendering engine.
> would there be any interest in adding commonmark support?
For now, I’m torn until you give me better examples than “no code block
support.” :)
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
