From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id AGSQAV8UoGbIUQEAqHPOHw:P1 (envelope-from ) for ; Tue, 23 Jul 2024 20:36:47 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id AGSQAV8UoGbIUQEAqHPOHw (envelope-from ) for ; Tue, 23 Jul 2024 22:36:47 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=hfmdk-frankfurt.de (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1721767006; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=35kUC4YU0P17xmwXY/TJJnbQ3p5rC4Kx9tbVgxJe+S8=; b=AxWRVd1NLL4IXdMypRhL9/LDlhP6g90WrLiBpzE/DOCpAhBjWNSkBvLoS0gzSh28Mvj6nW uDx1TNdwDeaqHM8Dg9oX3f45ls2CF8oYELFJq0WERPjYsQiO/Dn+6xVm+J99KbCGyd6DLg U8UKWoS3DDP7PXPNQYxjazfxCQSvauc/58gJNXXL3ox98P3aZPFidINOcCjOzgadS4XAmf Br8bAz3JCnGxpQ0XvNtWKWfVpqSSqveV2T7vd5oQce02q6vOa2X8rgRn22KZuapVI9fGHG T9WJ6hmXOVptLgXHNS0BwmXHDNHbuMChQ7ru16dECgPyuSdBwJj7/vsgFZnStw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=hfmdk-frankfurt.de (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1721767006; a=rsa-sha256; cv=none; b=QQxS5tLfGM6ljklbK885+3YZ3kGNo0SNm2X9+ffhHVXk8FDn+PogWv2ZDc6GQyIDUBj6ij Ds63WQQ5L7xZiRAfbram7CdEoxnLJnzwveyPPt2uRn+QyTHOZo70v9sKrsRN513hp/Xlcz +iCWsDfl5W9dEgwBFe55ux2URZ+ouO2RgUFSZJ9P85WKOdaeUZKjfmc6fddFmDJEsi1En1 OQXAxTGwBA5V9PbBVsSGUcpfX7eVnR1kmm1AE3smeyJTyLnKV0gyPUb+LkOQycLPxN40X9 m1ZpSXdsK24qA3ciEW5sCrXK4Mh8gbSTo1RSqOCc2BIAMQgomnGkdWqaDxt56A== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id EAB3B6B070 for ; Tue, 23 Jul 2024 22:36:45 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sWMEf-0001aB-ON; Tue, 23 Jul 2024 16:35:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sWMEc-0001a2-2z for emacs-orgmode@gnu.org; Tue, 23 Jul 2024 16:35:47 -0400 Received: from www.selma.hfmdk-frankfurt.de ([46.4.92.145] helo=mail.selma.hfmdk-frankfurt.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sWMER-00031x-4W for emacs-orgmode@gnu.org; Tue, 23 Jul 2024 16:35:38 -0400 Received: by mail.selma.hfmdk-frankfurt.de (Postfix, from userid 113) id CB3F3F61BF9; Tue, 23 Jul 2024 22:35:31 +0200 (CEST) Received: from selma.hfmdk-frankfurt.de (ip-037-201-128-004.um10.pools.vodafone-ip.de [37.201.128.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by mail.selma.hfmdk-frankfurt.de (Postfix) with ESMTPSA id 6434EF61BF9; Tue, 23 Jul 2024 22:35:29 +0200 (CEST) Received: by selma.hfmdk-frankfurt.de (Postfix, from userid 1000) id E442D3960515; Tue, 23 Jul 2024 22:35:28 +0200 (CEST) Date: Tue, 23 Jul 2024 22:35:28 +0200 From: Orm Finnendahl To: Ihor Radchenko Cc: Org mailing list Subject: Re: multipage html output Message-ID: Mail-Followup-To: Ihor Radchenko , Org mailing list References: <87r0c05com.fsf@localhost> <87wmlp38gr.fsf@localhost> <874j8gz9qh.fsf@localhost> <87bk2o2o2m.fsf@localhost> <87sew011c6.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87sew011c6.fsf@localhost> X-Disclaimer: Why are you listening to me? X-Operating-System: GNU/Linux Organization: Hochschule =?utf-8?B?ZsO8?= =?utf-8?Q?r?= Musik und Darstellende Kunst Frankfurt, Frankfurt, Germany Received-SPF: pass client-ip=46.4.92.145; envelope-from=orm.finnendahl@selma.hfmdk-frankfurt.de; helo=mail.selma.hfmdk-frankfurt.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: EAB3B6B070 X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -5.82 X-Spam-Score: -5.82 X-TUID: njSABDJ6qfzE 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