Am Dienstag, den 23. Juli 2024 um 17:10:17 Uhr (+0000) schrieb Ihor Radchenko: > > 2. If a transcoder for org-data is defined, call that and return nil > > from org-export-date. > > > > Otherwise return the transcoded string. > > > 3. In case a string is returned, process it as it is done in > > org-export-transcode-page (only that the output string will be > > supplied in place of the headline and we will find a better name for > > org-export-transcode-page as it is called *after* the transcoding. > > No. > > If a transcoder for org-data is defined, call it and return whatever it > returns. Otherwise, call `org-export-transcode-page' (adjusted to follow > transcoder arguments).
Sorry, this is still quite obscure to me: Why should a transcoder for org-data return anything in the multipage case and who should handle the return value(s)? The transcoder could return a list of strings which can get returned by org-export-as and then handled in the function which called org-export-as. If that's what you mean I can implement it, although I'm admittedly not really convinced, especially as there are hairy details to solve, when we really want to use org-export-data to generate multiple return values: - what should 'results in org-export-data be when calling the transcoding function for multipage? A list of strings returned by the transcoding of the individual pages? Shall each string be memoized? How? How to deal with assigning a file-name to each string, should we rather return a (filename . transcoded-string) alist? To recapitulate: In my code, org-export-as calls process-multipage in the backend. This function: - collects and adds information necessary for org-multipage to do its job, splitting the document into different parts, etc. and - then calls org-export-data on the subtrees and exports each returned string to an individual file. - It finally issues a done string and executes a browser open/visit file or simply exits nil. For me this is rather clean and it seems unnecessary to go through all the hassle of dealing with a multipage transcoder within org-export-data. Anyway, I will try to follow your recommendation once I fully understand what you're up to, although I fear this will open a can of worms... > > > 1. org-export-data has to be modified to catch the case of > > org-export-transcoder being called on org-data in the > > multipage-case (after ;; Element/Object with contents.). This seems > > a bit complicated as there is memoization going on in > > :exported-data of info further down in org-export-data which > > probably should get circumvented in the multipage case (e.g. by > > checking the value of results). > > I do not fully understand the problem you are describing here, but hope > that my clarification above resolved it. > Unfortunately not :-( Sorry that I can't really make sense of your explanations. Somehow we seem to think from quite different perspectives and it is really hard for me to get your point (although it is also fascinating and I'm not willing to give up ;-) > > 2. The code has to define/provide a transcoding function in the > > multipage case but should *not* provide such a function in the > > single page case, which means (in the multipage case) to modify the > > alist of the backend on-the-fly before calling org-export-as. > > I propose to allow custom org-data transcoder for single page case as well. > If there is no need to have custom transcoder for single page, the > custom transcoder can check :multipage property and fall back to > calling `org-export-transcode-page' if it is nil. ok, that much is clear. -- Orm
