[breuleux]

Could you be more specific as to what looks too much like source code? The most common difference between the two would be *multi word emphasis* vs _[multi word emphasis]. The former may be less conspicuous, but both read fine to me.

[charles_f]

Sure. What I mean is that quaint files (e.g. [1] and [2]) look like simplified HTML ; you're defining functions, div hierarchy, formatting and such. I cannot comfortably read the .q, I have to read the rendered HTML. On the other hand, this [3] looks like a text file with ASCII formatting ; the fact that it compiles to HTML is almost incidental.

[1]: https://github.com/breuleux/blog/blob/master/content/about.q [2]: https://github.com/breuleux/quaint-doc/blob/master/content/i... [3]: https://raw.githubusercontent.com/breuleux/earl-grey/master/...

[breuleux]

I mean, okay, I can see that, but they're not really equivalent examples, are they? The README isn't setting up a carousel, dealing with custom styles, or embedding an interactive example. There isn't really any way to implement these two Quaint examples that won't look like code. [1] or [2] are more representative of using Quaint like Markdown, although in that situation it's less clear what the advantages are, because there's not a lot in there that Markdown would do poorly.

[1] https://raw.githubusercontent.com/breuleux/blog/master/conte...

[2] https://raw.githubusercontent.com/breuleux/blog/master/conte...

In any case, it does appear the discoverability of straightforward examples leaves something to be desired, so thank you for making me realize that.

To me the advantages of Quaint is that I can easily define custom operators to do nonstandard things unobtrusively. For instance, if for some reason I want to emphasize some words in italic orange, I can easily set it up so that e.g. /xyz would highlight xyz in italic orange. Silly example, but there are a lot of valid use cases.