Hello, Christian Egli <christian.e...@sbs.ch> writes:
> Nicolas Goaziou <n.goaz...@gmail.com> writes: > >> If nothing has been started once the new export framework is installed >> and the early bugs are fixed, I will do the port. > > I don't quite understand why we need to "port" anything. The taskjuggler > exporter is different than the other exporters in that it doesn't really > export the content of an org file. Instead it just goes through the > headlines (using the mapping API), takes some to be tasks and reads the > properties of these headlines to build the taskjuggler file. It pretty > much ignores any text that is between the headlines (see also the > commentary in org-taskjuggler.el). In essence it treats the org file as > a tree of nodes with properties that define the tasks, resources and > reports. What it really exports isn't important. ox.el is a framework to export any part of an Org buffer (including non-contiguous parts like headlines only) to another format that can be, at least during an intermediary step, written as a string. In a export back-end, you basically specify an export action for each type of syntax. If nothing is provided, that the syntax will be ignored. In this case, the taskjuggler back-end would only provide a function for headlines. > It doesn't use any of the common (old) exporting > infrastructure. To be honest, I only gave it a cursory look, but it requires "org-exp" and uses a few functions from from it, like, e.g. `org-default-export-plist', `org-infile-export-plist', `org-install-letbind'. Some work needs to be done at this level. > So woudn't a "ported" org-taskjuggler.el look exactly > like to one that we have today? Externally, it would, hopefully. Internally, some changes are required. I also think it would much benefit from it, but I'm biased, obviously. Regards, -- Nicolas Goaziou
