4 ms·

The article describes Markdown[1], basically. In my opinion, content should be written once and transformed to any format[2], including ConTeXt[3], docx, HTML,

The article describes Markdown[1], basically. In my opinion, content should be written once and transformed to any format[2], including ConTeXt[3], docx, HTML, EPUB, or plain text. But here's a puzzler. Every software developer defines and uses variables. If variables are so powerful, why do WYSIWYG word processors lack the ability to quickly and easily insert variable definitions?[4] In the screenshot, the left-hand side provides an editable variable definition hierarchy, the middle pane provides a Markdown editor, and the right-hand side provides a real-time HTML preview of the content with variables interpolated and substituted. After variables, programming language integration--such as R[5]--comes naturally. Consider the following syntax (that could be hidden through a UI): `r#csv2md('data.csv',totals=TRUE)` The function imports data from an external data source and converts it to Markdown. The HTML version can be styled, or piped through pandoc to create beautiful PDF output[6]. In the screenshot, the left-hand side shows the csv2md command (totals are calculated automatically for numeric columns), the middle pane shows an HTML preview (real-time), and the right-hand side shows a PDF produced from the same source document using pandoc and ConTeXt. The CSV file could also be a JSON request over HTTP, or database query, meaning that the document is always up-to-date with the most recent data: a living document. This could be accomplished without having to change the source document, as well: `r#import(v$data$source,totals=TRUE)` Here, v$data$source is a variable that defines a data source. In this case, the value might be 'data.csv', but could be 'protocol://host/app/api/json'. The variables themselves could be sourced from a YAML file, JSON data stream, or remote database. This is what I've been working towards for the last several months.[7] There's more that this editor can do, but it's still in early beta stages, should anyone care to try it. [1]: https://github.com/jgm/pandoc/issues/168 https://github.com/jgm/pandoc/issues/168 [2]: http://pandoc.org/ http://pandoc.org/ [3]: http://wiki.contextgarden.net/ http://wiki.contextgarden.net/ [4]: https://raw.githubusercontent.com/DaveJarvis/scrivenvar/master/images/screenshot.png https://raw.githubusercontent.com/DaveJarvis/scrivenvar/mast... [5]: https://github.com/bedatadriven/renjin/ https://github.com/bedatadriven/renjin/ [6]: http://i.imgur.com/Qe6mTpx.png http://i.imgur.com/Qe6mTpx.png [7]: https://github.com/DaveJarvis/scrivenvar https://github.com/DaveJarvis/scrivenvar

skierscott 10y ago
Hm... I think this post is trying to solve a different problem. Markdown solves the problem of having content (paragraphs, lists) syntax free. This post: > What if you had to write a language where you can make mistakes, but there are no errors? Where your parser just silently accepts anything you give it. Where you'll have to carefully compare your intentions to the parsed output to figure out what went wrong. > Do you write HTML? > What I just described was how browsers handle HTML. They will happily accept anything you give them and try their best to make sense of it. They could swap out element places, change attributes, or do whatever if there's a typo in your code. Looks like they're trying to make make an easy-to-write HTML for all HTML, not just content.
- thangalin 10y ago
  > Looks like they're trying to make make an easy-to-write HTML for all HTML, not just content. Yes. I know it's a long thread, but pandoc issue 168 and the proposed "foolproof" syntax are, in essence, addressing the same issue. They both strive to shroud the nuances of HTML syntax in simpler clothing. Computationally, there's insignificant difference between this (proposed syntax): ; --- div {.foo} ; Ipsum dolor sit amet And this (foolproof syntax): div class:foo Ipsum dolor sit amet What Markdown doesn't have, as you allude to, are data bindings necessary to drive an interactive experience. Although, with a little ingenuity, a processor could provide data binding with a Markdown-compatible syntax, such as: ; --- input {.email} ; Email ; --- shuttle {.from} ; Available List ; --- shuttle {.to} ; Selected List From a high enough perch, they both look the same.
  - sakamies 10y ago
    Westoncb said it quite elegantly: "I think the core idea involved is a shift away from using text as a model for representing programs; instead, interact with more abstract representations of code, and render those abstractions as text. This allows your editor to have better understanding of the language you're using, so syntax becomes a property of a language's visualization rather than something totally central to it (and now you don't have to memorize it!)." Foolproof HTML of course tries to do that only for HTML, but I do hope I can expand it to CSS, JSON and maybe generalize it later on. So I'm not advocating for any specific syntax, but rather a way to edit html so you don't need to care about the syntax. The HTML syntax would still be there in the .html (or .erb, .php or whatever your template language is) the same as it has always been, but you could visualize it in a way that's most comfortable to you and edit it as a structure, so it would be impossible to produce syntax errors. This could end up being a text editor plugin or a stand alone app, some sort of library or kind of anything, but I'm prototyping interactions and ideas as a standalone web app because that's what I'm good at.

skierscott 10y ago

Hm... I think this post is trying to solve a different problem. Markdown solves the problem of having content (paragraphs, lists) syntax free. This post: > What if you had to write a language where you can make mistakes, but there are no errors? Where your parser just silently accepts anything you give it. Where you'll have to carefully compare your intentions to the parsed output to figure out what went wrong. > Do you write HTML? > What I just described was how browsers handle HTML. They will happily accept anything you give them and try their best to make sense of it. They could swap out element places, change attributes, or do whatever if there's a typo in your code. Looks like they're trying to make make an easy-to-write HTML for all HTML, not just content.

thangalin 10y ago
> Looks like they're trying to make make an easy-to-write HTML for all HTML, not just content. Yes. I know it's a long thread, but pandoc issue 168 and the proposed "foolproof" syntax are, in essence, addressing the same issue. They both strive to shroud the nuances of HTML syntax in simpler clothing. Computationally, there's insignificant difference between this (proposed syntax): ; --- div {.foo} ; Ipsum dolor sit amet And this (foolproof syntax): div class:foo Ipsum dolor sit amet What Markdown doesn't have, as you allude to, are data bindings necessary to drive an interactive experience. Although, with a little ingenuity, a processor could provide data binding with a Markdown-compatible syntax, such as: ; --- input {.email} ; Email ; --- shuttle {.from} ; Available List ; --- shuttle {.to} ; Selected List From a high enough perch, they both look the same.
- sakamies 10y ago
  Westoncb said it quite elegantly: "I think the core idea involved is a shift away from using text as a model for representing programs; instead, interact with more abstract representations of code, and render those abstractions as text. This allows your editor to have better understanding of the language you're using, so syntax becomes a property of a language's visualization rather than something totally central to it (and now you don't have to memorize it!)." Foolproof HTML of course tries to do that only for HTML, but I do hope I can expand it to CSS, JSON and maybe generalize it later on. So I'm not advocating for any specific syntax, but rather a way to edit html so you don't need to care about the syntax. The HTML syntax would still be there in the .html (or .erb, .php or whatever your template language is) the same as it has always been, but you could visualize it in a way that's most comfortable to you and edit it as a structure, so it would be impossible to produce syntax errors. This could end up being a text editor plugin or a stand alone app, some sort of library or kind of anything, but I'm prototyping interactions and ideas as a standalone web app because that's what I'm good at.