[O] Re: unnumbered subsections in latex export

[Nick Dokos]

Jambunathan K <address@hidden> 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