i wish _x_ in markdown wasn't interpreted as emphasis. we already have *x* for that. i'd use _x_ for subscript instead of ~x~ which looks more like strikethrough or something

@trwnh in the auld days of lore, *x* was for bold, /x/ for italics and _x_ for underline. Markdown's conflation of *x* and _x_ was a step back. AsciiDoc gets it a bit better by using *x* for strong and _x_ for emphasis. But it uses ~x~ for subscripts to mirror ^x^ for superscripts.

@oblomov i don't see the "mirror" between ~ and ^ -- i think _ could make sense for underline or subscript but the way i'd approach that is _sub_ and __underline__

anyway this is probably one of those things i'll have to fallback to html for

@trwnh I don't see the mirror either, FWIW, I would have used ~x~ for strike-through. It can't be __x__ in AsciiDoc because the double symbols are used to support in-text formatting (**b**old would mark the first letter as strong). But yes, there's only so many symbols so at one point or another fallback is kind of unavoidable

@oblomov fwiw i'm mostly approaching this from the perspective of "what should i use while authoring my own markdown content in hugo" and by extension "what should i recommend other people use if they want to install my theme"

@trwnh (it's a bit sad that the answer to that seems to be “just use HTML” then 8-P)

@trwnh FWIW, personally I'm getting quite tired of Markdown limitations, and have been using AsciiDoc(tor) more whenever I can. Of course It has its own set of limitations, but for example it has this generic “span” markup that allows thematic customization (e.g. one can do [.strike]#x# and define a CSS class for strikethrough —could even be more semantic than HTML's <s>).

@trwnh (ah, and this is NOT a “you should be using AsciiDoc BTW” post, BTW 8-D)

@oblomov if asciidoc had anything like hugo's render hooks for markdown then maybe i would seriously consider it

@oblomov WIP of course but this is what i have so far

@oblomov

@oblomov i should probably note one thing that might look weird at first glance -- i am choosing to render quotes as articles instead of as figures. normally to associate a blockquote's caption with the blockquote itself, you would use figure and figcaption. but figure has semantics of being able to take it out of the flow and put it anywhere else. this is not something i generally want, as i usually use quotes in-flow instead of out-of-flow

@oblomov also also: regarding the "span" markup you mention, there is a proposal for inline attrs for markdown via []{} which works similarly to the block attrs extension which uses {} at the end of a block

@trwnh wait shouldn't it be the other way around? It's up to Hugo to support asciidoc as a rendering engine? I don't use Hugo but last time I checked the docs while looking for an alternative to Ikiwiki I think I read it did support it? Or am I missing something?

@oblomov hugo does support asciidoc rendering via asciidoctor, but it's not as wildly configurable as markdown rendering via goldmark

@trwnh I've seen some of the samples later (sorry for forking the thread), and it seems most of that stuff you want to do is actually supported natively by AsciiDoctor, but I think I see your point. I'm not familiar with goldmark, but I'm getting the impression that it's something similar to what Jekyll with their {% %} escapes, except that this happens “during” rendering with a callback to Go or something like that? Yeah, I can see how that's a feature one wouldn't like to go without.

@oblomov yeah i *think* you can write custom renderers in ruby and then somehow configure asciidoctor to use those custom renderers? but hugo's render hooks abstract away a lot of that and let you write templated html directly instead of writing functions that produce strings which happen to be html