From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id kNk/FQVCumZAEwAAqHPOHw:P1 (envelope-from ) for ; Mon, 12 Aug 2024 17:10:29 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id kNk/FQVCumZAEwAAqHPOHw (envelope-from ) for ; Mon, 12 Aug 2024 19:10:29 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=aKxb3Tcc; dmarc=pass (policy=none) header.from=posteo.net; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1723482629; 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:dkim-signature; bh=7jzBhCVtK6W1No4VIMWWiTlw1zk3kOEN+JmQ3Jt80AY=; b=TCGtRunfYLdXJJ+hHW4wFxYSIgdPgztyZkN4YN9Z52DpaTb5WeIdAf7sqXyWqR6Fx9n1El mqhP7inEchtyoJvGv44qbnVXiayWHme75bEsa4s1+6aROvn0KnwSnd+clnna0rnc8yZTyM Xyol1SoEMdVZ4ZzeJppP9dStU5O0Xirtxf9bDWaxgd5PDhYW5wbZd7grKmsc5MEzjL+jry pk3v9BTgPuaHzZ9dXZYyQCszuWyKg9YaOWglo2xaVsCiotQZzcwl8lFvVXFuRhtfe0He56 zBBEI4bKb47drJBFBkvpQcQvnwxOpWYhHgDKE5pwWtMituBK4rRQdb8VndI83g== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1723482629; a=rsa-sha256; cv=none; b=RpPqODhE++zVKW0FjftJdtebmW7LHz1OgSOSfPq9NcoPqXPa5XAteXNqGvU2F6A1SUhsZg dHePH3uxYVn9oCsKoxSLUde/PcKaIHu5ID2eHeHpn8dqGFpQEDBQnc6wxIFYjWY67AeqfY blNpr6B/BeRLIfV8UiPuroSVZx8NpuHvg4VDcKyDNCBVqWSt5MKJPvOr3VLqzPiMGyM7jf mrRwUDfoHbCkvSGYCFEeBHa1jhfXVB/zo4r5H09kxlW57ZmSFOh7SBXROXT0S/XjaCBBQn w2g+A6NNflChuHJZNaDXJ+K0JNT1JUillTOrTyogmz8HqKREFaC5QaRelhtPJg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=aKxb3Tcc; dmarc=pass (policy=none) header.from=posteo.net; 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" 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 044313E952 for ; Mon, 12 Aug 2024 19:10:29 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sdYXy-0002dO-2o; Mon, 12 Aug 2024 13:09:30 -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 1sdYXw-0002d5-1z for emacs-orgmode@gnu.org; Mon, 12 Aug 2024 13:09:28 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sdYXq-0006y1-JT for emacs-orgmode@gnu.org; Mon, 12 Aug 2024 13:09:27 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id A2C27240027 for ; Mon, 12 Aug 2024 19:09:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1723482556; bh=SsnjRGviEZ5Y89EVbbNcEnObWlnysPD5N2ipX09oVYI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=aKxb3TccUFJhifkWfu+WEPhLL4YMDahaxvNq+Oy9kGU3YKn1OqDLiXjK6PHj9qPAh 10auFNtBvu1AbKhVGF9zi5EhGwufpb44miON0AHbWxNeSfUyY38qs3aqnKQQ16aMWb KUpiGRcAzvIlAv9oJ4LnsKZcb+XVFg1akaymijRebFTYXZ2dDmQucuYWSCQ3t1iKql lb8/wa3bNjKREGbwueFz0Qs5iedg1RNArpHaaylWQT0MZTun7dTJg2SUKgPun2iZOT yXPQWc15ZHLlLbUjQGsMBmC+kJ36FBIWWNUDoKch/Ja0uX8yyFko907/lHoR47FQyS bH/Rydx7oz5xw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WjLbH4NHVz6twx; Mon, 12 Aug 2024 19:09:15 +0200 (CEST) From: Ihor Radchenko To: Orm Finnendahl Cc: emacs-orgmode@gnu.org Subject: Re: multipage html output In-Reply-To: References: <87plr14wka.fsf@localhost> <87bk2i8w07.fsf@localhost> <87r0b2kext.fsf@localhost> <87zfpk36er.fsf@localhost> <87a5hjxjbh.fsf@localhost> Date: Mon, 12 Aug 2024 17:10:25 +0000 Message-ID: <87le11is5a.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.67 X-Spam-Score: -6.67 X-Migadu-Queue-Id: 044313E952 X-Migadu-Scanner: mx11.migadu.com X-TUID: /IsVpWB5dwOY Orm Finnendahl writes: > I made the changes Ihor suggested and made all docstrings compliant > with checkdoc. Please check whether this is now how you imagined it. Thanks! I still have comments, but let's not focus on this minor issue yet. > Concerning the options stored in the org-page properties rather than > in info I mentioned in an earlier mail, I found out it actually > doesn't really change anything substantially or clarifies/reduces the > code, so I decided against it. ATM it doesn't make all that much > sense to me. Ok, but I am seeing > (defun org-export-transcode-org-page (org-page _ info) > ... > (let* ((body-only (org-element-property :body-only org-page)) > ... > (put-text-property > 0 1 :output-file (org-element-property :output-file org-page) final-output) which is still relying upon custom properties. > If we're nearing code completion, we could also start tackling the > documentation. I think there should be an addition for the multipage > filter in ox.el (under "Filter System") and maybe some other additions > to explain the mechanism for multipage output (where?) > Maybe I can also get some assessment what's needed in org-manual and > what to change in order to make the doc additions proposals I made > compliant with the rest of org-manual. No, we are not nearing code completion. I am just getting started on the review process. We still need to decide and finalize the changes to export system that we need to adapt globally, without tying it to ox-html exporter. We are still at high-level review stage. See the next set of comments below > (defun org-export--annotate-info (backend info &optional subtreep visible-only ext-plist) > ... > (when (plist-get info :multipage) > (setq tree (org-export-filter-apply-functions > (plist-get info :filter-multipage) > (funcall > (plist-get info :multipage-split-function) tree info) :multipage-split-function should be added to the :translate-alist I think. It should be documented what :multipage-split-function is supposed to do in the docstring of `org-export-define-backend'. I do not feel like :multipage-split-function is supposed to be export _option_. It is more internal. That's why :translate-alist, where the internals like templates and transcoders lie. > (defun org-export-transcode-org-page (org-page _ info) > ... > (let* ((body-only (org-element-property :body-only org-page)) > (info (cl-list* ;; add :tl-headline and :tl-headline-number to info > :tl-headline headline > :tl-headline-number > (alist-get > headline > (plist-get info :headline-numbering)) > info)) May you please explain what is the purpose of constructing custom INFO plist, what all these parameters do, and why you re-do the export again in the transcoder discarding the CONTENTS argument provided? > (defun org-export-transcode-org-data (data body info) > "Transcode DATA with BODY. Return transcoded string. > DATA is the top `org-data' node of the parse-tree. INFO is the > communication channel plist." > (if (plist-get info :multipage) > ;;; for multipage output the `org-data' node contains `org-page' > ;;; pseudo elements as contents, so we call `org-export-data' on > ;;; each of them and return the collected results. > (mapcar (lambda (org-page) > (org-export-data org-page info)) > (org-element-contents data)) This is not a transcoder's job to export its contents. Please move special handling of org-page AST nodes to `org-export-data'. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at