From: Nick Dokos <nicholas.dokos@hp.com>
To: Jambunathan K <kjambunathan@gmail.com>
Cc: Bastien <bzg@altern.org>, nicholas.dokos@hp.com, emacs-orgmode@gnu.org
Subject: Re: unnumbered subsections in latex export
Date: Fri, 01 Apr 2011 02:29:57 -0400 [thread overview]
Message-ID: <6182.1301639397@alphaville.dokosmarshall.org> (raw)
In-Reply-To: Message from Jambunathan K <kjambunathan@gmail.com> of "Fri, 01 Apr 2011 10:04:54 +0530." <81y63u7fo1.fsf@gmail.com>
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
next prev parent reply other threads:[~2011-04-01 6:30 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-22 12:10 unnumbered subsections in latex export Suvayu Ali
2011-03-22 12:20 ` Sébastien Vauban
2011-03-22 12:31 ` Suvayu Ali
2011-03-22 12:56 ` Sébastien Vauban
2011-03-22 14:26 ` [PATCH] Allow mixed export of numbered and unnumbered sections in LaTeX Lawrence Mitchell
2011-03-22 22:52 ` Suvayu Ali
2011-03-23 14:04 ` [Accepted] " Bastien Guerry
2011-03-23 14:17 ` [PATCH] " Bastien
2011-03-22 14:35 ` Re: unnumbered subsections in latex export Nick Dokos
2011-03-22 23:08 ` Suvayu Ali
2011-03-22 23:21 ` Nick Dokos
2011-03-23 9:38 ` [PATCH] Allow mixed export of numbered and unnumbered sections in HTML Lawrence Mitchell
2011-03-23 14:05 ` [Accepted] " Bastien Guerry
2011-03-23 14:57 ` Nick Dokos
2011-03-23 15:50 ` Suvayu Ali
2011-03-23 14:18 ` Re: unnumbered subsections in latex export Bastien
2011-03-23 15:02 ` Nick Dokos
2011-03-23 16:25 ` Lawrence Mitchell
2011-03-23 16:42 ` Nick Dokos
2011-03-23 18:17 ` Jambunathan K
2011-03-23 19:00 ` Nick Dokos
2011-03-23 19:18 ` Jambunathan K
2011-03-23 16:29 ` Thomas S. Dye
2011-03-23 17:42 ` Jambunathan K
2011-03-24 7:59 ` Bastien
2011-03-24 18:27 ` Achim Gratz
2011-03-24 19:25 ` Nick Dokos
2011-03-25 1:06 ` Suvayu Ali
2011-04-04 14:39 ` Sébastien Vauban
2011-04-04 17:04 ` Nick Dokos
2011-04-04 20:32 ` Aankhen
2011-04-05 10:16 ` Sébastien Vauban
2011-04-05 19:07 ` Aankhen
2011-04-05 19:27 ` Eric S Fraga
2011-04-05 21:25 ` New features for the exporters? Sébastien Vauban
2011-04-05 21:45 ` Re: unnumbered subsections in latex export Aankhen
2011-04-06 18:49 ` Matt Lundin
2011-04-06 20:19 ` Sébastien Vauban
2011-03-27 11:16 ` Jambunathan K
2011-03-27 11:40 ` Bastien
2011-03-31 21:58 ` Nicolas
2011-04-01 4:34 ` Jambunathan K
2011-04-01 4:41 ` Jambunathan K
2011-04-01 6:29 ` Nick Dokos [this message]
2011-04-01 15:41 ` Eric S Fraga
2011-04-04 14:00 ` Matt Lundin
2011-04-04 14:12 ` Jambunathan K
2011-04-04 16:36 ` Matt Lundin
2011-04-04 17:09 ` Nick Dokos
2011-04-01 7:39 ` Jambunathan K
2011-04-01 18:25 ` Achim Gratz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6182.1301639397@alphaville.dokosmarshall.org \
--to=nicholas.dokos@hp.com \
--cc=bzg@altern.org \
--cc=emacs-orgmode@gnu.org \
--cc=kjambunathan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).