Orm Finnendahl <orm.finnend...@selma.hfmdk-frankfurt.de> writes: >> Or we can make `org-export-as' retain INFO channel when returning the >> output. Then, we can make `org-export-to-file' make use of the INFO >> channel to decide the file name. This way, there will be no need to >> decide the file name before running the parsing. > > Are you sure that works? org-export-as currently returns a string. It > could in addition return the parse-tree in info, plus the smaller > parts which need to be exported, but we should not forget, that > org-export-as is an inferior function called from org-export-to-file > or org-export-to-buffer. But maybe I misunderstand what you mean.
That's exactly what I mean. > Here is what is needed from my perspective: > > 1. parse the tree of the whole document > > 2. split the tree up. > > 3. call the export backend on each of the split parts to generate the > string and save it to disk or do whatever is appropriate. > > For me the most natural way would be that a central function > (export-according-to-org-property-list) does the parsing and then call > the different backend functions to export according to their rules > (the trees being converted in the central function or in backend > code). > > If toplevel functions like org-export-to-file use org-export-as, than > org-export-as should only be concerned with generating the string but > not with reparsing. Sorry, but I do not understand your concern. > Alternatively we can do the conversion to a string in the central > function as now with org-export-as, but there still needs to be a > mechanism to generate the different files for multipage output and > call the export backend on them to save them or whatever. Or what did > you have in mind? What I have in mind is that `org-export-as' will return a list of strings + INFO. INFO will contain data about which files to use for saving the strings. Then, the caller does the saving and whatever is necessary. If we write to files from `org-export-as' it will be a massive breaking change in the expected behavior. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
