Jambunathan K <kjambunat...@gmail.com> wrote: > Do look at my new html exporter. I have been very conservative in making > the changes. > Well, Nicolas's proposal is more radical, but there is no inherent backward compatibility disadvantage to it that I can see.
> Some observations from my side ... > > > It isn't documented enough because some of those properties are not > > exactly defined, and their meaning, or their differences, aren't > > always explicit (org-protected, org-example, org-verbatim-emph are > > coming to my mind). > > I agree that text properties are problematic. I see that they are also > used inconsistently. > > When I see backend specific code in org-exp.el something in my gut says > that it is not OK. > Absolutely. It is the price that one has to pay when trying to add new features to a system that has become successful and you don't dare break backward compatibility: sometimes you have to resort to ugly hacks. Think Windows e.g. which by now is riddled with ugly hacks, partly because they don't want to give up backward compatibility. Lest I give the wrong impression, let me say that even though org has dark and ugly corners here and there, overall it is a thing of beauty. Windows, not so much :-) > For example, source blocks are transformed in org-exp.el to > html-specific markup and get inserted between #+begin_html and > #+end_html with org-indentation, org-protected properties. org-html.el > just inserts it. > > I believe, it would be all the more better if the above "transform & > propertize in org-exp.el and just insert in org-html.el" is done as > "propertize in org-exp.el and transform & insert in org-html.el". > IIUC, Nicolas proposes to make the exporters behave more like a modern compiler: there is an intermediate representation (an attributed tree) that the org document is transformed to. Then there is a standard tree walker that walks the tree and does callbacks to backend-specific functions. Each backend is responsible for providing this well-defined set of functions. If a new syntactic or semantic element is introduced that necessitates a new type of node in the tree, then the walker would call a new function to handle the new node type: each backend would have to implement this new function. As compiler writers have found out, this makes it much easier to support a new backend. > [Context Switch] > Html exporter is not only line-oriented it is also a transformation > pipeline. The latter part means that if lines are slightly arranged > (that is the order of the transformation is changed) then things will > break in unexpected ways. > > This is the root cause of all the recent regressions concerning images > and timestamps in the HTML exporter. > > [Context Switch] > org-html.el opens paragraph in anticipation rather than when it is > actually needed. As a result previous context just diffuses in to a > latter context. If this were not so deleting of empty paragraphs > wouldn't be necessary. > > [Context Switch] > HTML exporter occasionally emit things temporarily and goes back and > fixes it. Table's colalign and colgroup markers come to mind here. In > some sense convenience features like "right align if a column is > predominantly numeric" also complicated things. > > I think one of the reasons Org is so popular it is that it is a > common-man's swiss army knife and not a elitist samurai sword. > To continue your analogy: sometimes the cut is a bit rough. It might be a good idea to use some of that elitist samurai sword metallurgy know-how in order to provide better blades for the swiss army knife. > Jambunathan K. > Nick
