From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nick Dokos <nicholas.dokos@hp.com>
Subject: Re: unnumbered subsections in latex export
Date: Fri, 01 Apr 2011 02:29:57 -0400
Message-ID: <6182.1301639397@alphaville.dokosmarshall.org>
References: <20110322051038.21655c80@kuru.homelinux.net>
	<80d3lj9wj6.fsf@somewhere.org>
	<20110322053134.669127e9@kuru.homelinux.net>
	<8999.1300804510@alphaville.dokosmarshall.org>
	<20110322160814.227fc53f@bhishma.homelinux.net>
	<27844.1300836065@alphaville.usa.hp.com> <8162r9hgxm.fsf@gmail.com>
	<87bp11dk4h.fsf@gnu.org> <87tyejymto.fsf@gmail.com>
	<81y63u7fo1.fsf@gmail.com>
Reply-To: nicholas.dokos@hp.com
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from [140.186.70.92] (port=56484 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Q5Xrt-0004Gf-8J
	for emacs-orgmode@gnu.org; Fri, 01 Apr 2011 02:30:02 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <nick@dokosmarshall.org>) id 1Q5Xrr-00041l-Ve
	for emacs-orgmode@gnu.org; Fri, 01 Apr 2011 02:30:01 -0400
Received: from vms173011pub.verizon.net ([206.46.173.11]:51511)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <nick@dokosmarshall.org>) id 1Q5Xrr-00041h-R3
	for emacs-orgmode@gnu.org; Fri, 01 Apr 2011 02:29:59 -0400
Received: from alphaville.dokosmarshall.org ([unknown] [173.76.32.106])
	by vms173011.mailsrvcs.net
	(Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16
	2009)) with ESMTPA id <0LIY006WQNDX5C80@vms173011.mailsrvcs.net> for
	emacs-orgmode@gnu.org; Fri, 01 Apr 2011 01:29:58 -0500 (CDT)
In-reply-to: Message from Jambunathan K <kjambunathan@gmail.com> of
	"Fri, 01 Apr 2011 10:04:54 +0530." <81y63u7fo1.fsf@gmail.com>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <http://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
To: Jambunathan K <kjambunathan@gmail.com>
Cc: Bastien <bzg@altern.org>, nicholas.dokos@hp.com, emacs-orgmode@gnu.org

Jambunathan K <kjambunathan@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