From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos 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: 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 ) 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 ) 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 of "Fri, 01 Apr 2011 10:04:54 +0530." <81y63u7fo1.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Cc: Bastien , nicholas.dokos@hp.com, emacs-orgmode@gnu.org Jambunathan K 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