Juan Manuel Macías <maciasch...@posteo.net> writes:
> To add some ideas that have been occurring to me these days... > > I am more and more convinced that inline special blocks, by their > nature, should not support fine tune options or anything like > attr_latex, attr_html, etc. like its older brothers, as it would produce > an overly complicated syntax. Big brothers are independent of the > paragraph and there it makes sense to add lines with attr_latex, etc., > since it is a line-oriented syntax. Bringing that into the paragraph is > unnecessarily overloading the paragraph and breaking the social contract > of lightweight markup, where paragraphs should still look like > paragraphs. > Agree. I think your reasoning here is spot on. > Another argument against possible fine-tuning within inline special > blocks, for export purposes, is that (in my opinion) direct formatting > is a practice that should be avoided as much as possible in a document. > A document with a lot of direct formatting is an inconsistent document. > In html, all possible formatting should be controlled by style sheets; > in LaTeX, by (re)defining macros, commands and environments in the > preamble or in a .sty file; in odt using character styles. > Agreed. In fact, I use in-line blocks so rarely that at first I wasn't going to respond as I really didn't have much skin in the game when it comes to inline blocks. The reason I dond't use them much is pretty much the same as your reasoning above. > Perhaps if we detach special blocks from fine-tuning possibilities we > lose some (export) flexibility, but we gain in a clearer implementation > of these elements and keep Org aseptic about the output format. And in > any case, if someone needs a fine-tuning in a certain case, there are > always the export filters. Or it can be implemented in a similar way to > inline tasks, with a default format function (for html, latex, etc), > which can be changed via a defcustom. > I also like this approach. We need some form of escape hatch. However, for uncommon edge cases, I would rather have a slightly less convenient escape hatch and a simple consistent general syntax than a more complex syntax which is difficult to maintain and keep consistent and reliable. > Starting from that, a syntax like this in Org: > > %[name]{contents} > > Would produce in LaTeX, by default: > > \name{contents} > > in html: > > <name>contents></name> or should that be <span class="name">contents</name>? > > in odt: > > <text:span text:style-name="name">contents</text:span> > > and so on. > > In short, I think it would be enough to simply implement something like > this. > Sound reasoning IMO.