emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: Henry Hirsch <henry.hirsch@adition.com>
Cc: Emacs-orgmode@gnu.org
Subject: Re: Include does not work when doing org-export-as-org
Date: Tue, 11 Oct 2011 20:27:06 +0200	[thread overview]
Message-ID: <BAA7304B-E444-471C-AD49-97461F630276@gmail.com> (raw)
In-Reply-To: <20111011143414.GA25699@olymp.office.virtualminds.de>

On 11.10.2011, at 16:34, Henry Hirsch wrote:

> On Tue, Oct 11, 2011 at 10:27:56AM -0400, Nick Dokos wrote:
>> In particular, I assume it does not process includes, because they need
>> to be preserved in examples.
>> Nick
> So do you think it is reasonable that org-export-as-org is the only mode
> of export which is exhibiting a different behaviour?
> For my part I think it is not. 
> I used to love org-mode above everything.
> But this just leaves me not amused.

What made you get out of bed today in a bad mood?

Maybe I can help to improve the communication
by explaining where the problem lies.
Both functionalities, the one that is implemented, and the
one that you want make a lot of sense.  The problem
is merely a misnaming of the function.

The reason why `org-export-to-org' was introduced was
solely to provide a way for a website to publish
the source file that was used to create a particular
website, along with the website itself.  An example can
be found on Bernt's site.


What the function does is (Nick already collected this info)

- remove archived trees and commented trees
- remove trees that are excluded by special tags
- output the resulting file with -source.org extension
  and optionally produce an htmlized version of this
  file so that the web visitor can look at the file.

Processing of #include files was left out on purpose, because
that often contains stuff which you want to have out of the way
because it is tedious or complicated.  In fact, a website can choose
to also publish the source of the #include files as separate files.

What you are looking for a mechanism to expand more directives,
in order to produce another org file.  You want (IIUC) a preprocessor
much like a C compiler preprocessor.  However, it is not
automatic what this should do and what it should not do.
For example

 - do you think it should expand macros?
 - oo you think it should process babel blocks and insert the
   evaluation results, as the other exporters do?
 - do you think it should process links into a standard format
   and pre-expand link searches?

I suspect (but that is a guess, based on the description
of your use-case) that your answer would be No to all
these questions.  Yet someone else could come in and
take issue with the absence of this processing, with all
the same right as you have to wonder about the absence
of #include processing.  It all depends and what you
actually want to achieve, and the answer is *not*

So while I am guilty of maybe misnaming this function, you will
have noticed that this "exporter" actually does not show up in
the export menu as an independent exporter - it is mainly used
by publishing projects.

We could use a new function which does a configurable amount
of processing, maybe it could get a number of arguments which
define what exactly should be done - and it should definitely
write to a different file, without clobbering the current file.
Maybe file_expanded.org or so?

The way to write this function is to start at `org-export-as-org',
keep what you like and add more stuff from org-export-preprocess,
for example a call `org-export-handle-include-files-recurse' as
one of the first things.  Really, `org-export-preprocess-string'
can be the guide of what can and should be done.

I could write such a function, Nick could, but first there needs to
be clarity of what this should achieve, and how to address this issue
in a general way.

- Carsten

  parent reply	other threads:[~2011-10-11 18:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-11 12:38 Henry Hirsch
2011-10-11 13:41 ` Nick Dokos
2011-10-11 13:53   ` Henry Hirsch
2011-10-11 14:01     ` Henry Hirsch
2011-10-11 14:09 ` Nick Dokos
2011-10-11 14:18   ` Nick Dokos
2011-10-11 14:21   ` Nick Dokos
2011-10-11 14:27     ` Nick Dokos
2011-10-11 14:34       ` Henry Hirsch
     [not found]         ` <henry.hirsch@adition.com>
2011-10-11 14:57           ` Nick Dokos
2011-10-11 15:09             ` Henry Hirsch
2011-10-11 15:37               ` Nick Dokos
2011-10-11 16:09                 ` Henry Hirsch
2011-10-11 16:51           ` Nick Dokos
2011-10-12  7:44             ` Henry Hirsch
2011-10-12 10:15               ` Carsten Dominik
2011-10-21 16:49                 ` Bastien
2011-10-21 17:14                   ` Nick Dokos
2011-10-11 18:27         ` Carsten Dominik [this message]
2011-10-11 14:22   ` Henry Hirsch

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:

  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=BAA7304B-E444-471C-AD49-97461F630276@gmail.com \
    --to=carsten.dominik@gmail.com \
    --cc=Emacs-orgmode@gnu.org \
    --cc=henry.hirsch@adition.com \


* 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


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).