91–100 of 272 posts
This can be done with Bitbucket but the existing marketplace plug-in has been broken since they added the connect/disconnect webhooks as mandatory. Of course, the plug-in is provided by bitbucket …so that’s fun. I wrote a trivial webstack to answer 200 to the webhook and then everything works. (Don’t know if I can publish it unfortunately.) (Condolences to those stuck on Bitbucket).
Earlier quoted context omitted.
Agreed; this is an annoying inconsistency. If you want to embed and render a non-Markdown file in Markdown, there's already another, far better syntax for that which is more in-line with the spirit of Markdown's "just text" philosophy: 
It's nice to have the diagram source in the same file that uses it, instead of a separate file that needs to be kept in sync.
So, the question is would you rather have SVGs inline?
Personally I think the reference to another file is a perfectly fine compromise, as the content is sufficiently different to no longer be markdown.
Earlier quoted context omitted.
Has Graphviz been re-implemented in JavaScript or compiled to WASM?
It's a simple well documented language. Righting a fully functional JS Graphviz parser from scratch would take a couple days at most.
Earlier quoted context omitted.
This seems to be incorrect, the current version has no CVEs according to that tracker.
I think the parent comment is just saying that multiple vulns have been found recently. There's a good chance there's more.
Earlier quoted context omitted.
You missed the point, that being; isn't triple backticks meant for whitespace preserving, highlighted in certain cases source code? And not embedding other file types.
No there's not a formal requirement or spec for how markdown blocks are rendered. Even things like syntax highlighting are optional choices different renderers make (and even the whole idea of highlighting is not specified or defined, how do you define the grammer, etc?). Some tools in the computational notebook space use markdown with fenced code blocks as blocks of executable code, see for example jupytext: https:/…
What’s debatable is what the spec does with the “info” section.
I think so-called ASCII-art is more in the spirit of Markdown. The nice thing about the original Markdown (modulo bugs) is that things are written the way one would write plaintext documents which are supposed to be easily read in a text editor. So you don’t write bullet lists like this: - Bullet 1 - Bullet 2 - Bullet 3 And hope that some post-processing will add linebreaks for you. You write it like this: - Bullet 1…
> Similarily there have been many tools that let you add so-called ASCII-art diagrams to Markdown documents. here-in is the nub. these are self contained(/embeddable?) editors of what is essentially non-textual content. there's a concealed inner data-model which is rendered/transpiled into text. i far far far far prefer a text mark up, which is easy to directly edit, which is fairly readable on it's own (imo mermaid…
Do they support a markdown Table of Contents yet?
I’m the main author of KeenWrite (see screenshots[1]), a type of desktop Markdown editor that supports diagrams. It’s encouraging to see that Mermaid diagrams are being supported in GitHub. There are a few drawbacks on the syntax and implications of using MermaidJS.
First, only browser-based SVG renderers can correctly parse Mermaid diagrams. I’ve tested Apache Batik, svgSalamander, resvg, rsvg-convert, svglib, CairoSVG, ConTeXt, and QtSVG. See issue 2485[2]. This implies that typesetting Mermaid diagrams is not currently possible. In effect, by including Mermaid diagrams, many documents will be restricted to web-based output, excluding the possibility of producing PDF documents based on GitHub markdown documents (for the foreseeable future).
Second, there are numerous text-to-diagram facilities available beyond Mermaid. The server at https://kroki.io/ supports Mermaid, PlantUML, Graphviz, byte fields, and many more. While including MermaidJS is a great step forward, supporting Kroki diagrams would allow a much greater variety. (Most diagrams produced in MermaidJS can also be crafted in Graphviz, albeit with less terse syntax.)
Third, see the CommonMark discussion thread[3] referring to a syntax for diagrams. It’s unfortunate that a standard “namespace” concept was not proposed.
Fourth, KeenWrite integrates Kroki. To do so, it uses a variation on the syntax:
``` diagram-mermaid
```
``` diagram-graphviz
```
``` diagram-plantuml
```
Fifth, if ever someone wants to invent a programming language named Mermaid (see MeLa), then it precludes the possibility of using the following de facto syntax highlighting:
``` mermaid
```
``` diagram-mermaid
```
``` mermaid
```
``` java
```
``` language-java
```
[1]: https://github.com/DaveJarvis/keenwrite/blob/master/docs/scr...
[2]: https://github.com/mermaid-js/mermaid/issues/2485
[3]: https://talk.commonmark.org/t/mermaid-generation-of-diagrams...