From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.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 eFDbM7bLhmYoTwAA62LTzQ:P1 (envelope-from ) for ; Thu, 04 Jul 2024 16:20:07 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id eFDbM7bLhmYoTwAA62LTzQ (envelope-from ) for ; Thu, 04 Jul 2024 18:20:06 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=LQHDiR7e; 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=1720110006; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=om7wFWmJQ/zjRUFFg4yD5z4u2n07z48Ai4PB3pZxQc0=; b=Qo1KutDxGRhr8HQCCzydWSNqOnshtfkH8rlydjoGzJojdFpwMs/5Gnrpf1rHoraZsSohhf m8S9qtUsoodBshGEiN8mRe2KK3K24BpUvo7+VYejirG7RVjaCW/KtTVEM4QQEjkNYzk2F7 vLqxd1ALXaFaZENmigSaknBfyBFP1wkdDRn569gRf+HrloKOvGH055YjND2j3UaDEXh59E GABrFjvcKJPk7GTp0SrdIqfS7jBdJ9mZktk79WlOg3Emrb51+F+RkE3SiYb59FGMT+a4vW 0ASToexBJk6WKY/5dzv/eahvKePV4ZHlCaJZCSc2REC6XZYPNxfSJKHwXuqiQQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1720110006; a=rsa-sha256; cv=none; b=gDhFt0pjejA0r0H9FWKMsNLrnMwDXhp4pqxBx38SM3/js7MEp+pJaXaKtIpb2Twg1G0cEr 4Ob6N33GoQZco3Dyrik1QZ+FHFQyH4YXUBfnRIsJ1Qa3zvx1FOmmTVT5fgBCv6SvP4KBzU n4t/DCgCcgzUkUsRjG1MAylZGITCBXtlZ+QKRSoBy8CBYuMkDPR2uxcbtpxAYmqfWxvNCb 881uobo2QG1CQkFrC0YMwbrIrYHAHCRFOEv7Bpmlu+W7rc4x7b9oZGc3wPk1t7zyFwLYFf STrx8Ugx2ZW4oOJZpLsY1iE6QVdZroCKK76aHUAuJIDoiEnbzoguZQcQ01t+tA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=LQHDiR7e; 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 7F3ADAEB4 for ; Thu, 04 Jul 2024 18:20:06 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sPPAo-0005Ln-Mc; Thu, 04 Jul 2024 12:19:06 -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 1sPPAm-0005LE-JZ for emacs-orgmode@gnu.org; Thu, 04 Jul 2024 12:19:04 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sPPAj-0002gX-Q9 for emacs-orgmode@gnu.org; Thu, 04 Jul 2024 12:19:04 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id B562A240103 for ; Thu, 4 Jul 2024 18:18:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1720109938; bh=S6LcPyzvqDgxQJ8vaYhp1njgyemmXcNVTqsNxngT0Ik=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=LQHDiR7egokbwG2+QJL2PB3eWPx2N6pg3gUkXYrTCq3IN3ZlsBJGPWWiWXbeFkbJY pN+vkh6C7aCPun+AL9VlmbMxRKqxe6/EDLrbwdsMzTB1DF08WvgPP9DDEkdJZz+9QT s6vumR7a4GTfFE5W5GDobSGK+v4XnTvlOV81ZcnvamSHfIOcOhMQq77dAlFlliQOzu HQT1lFVfzG0MLUTx8QLo61Et8dQtyVFjGzZUTaoFF3+alwvSlfb/HpUdBQ6bESgFtZ 8WSJ7NO1D5KxzJ6nDCb73AJ37u7JNHDTwuPdiJBdSbWj12i457VA9yDHK3jrKpAq53 hP4Kh92MhASoA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WFMKG1K4kz6tvn; Thu, 4 Jul 2024 18:18:58 +0200 (CEST) From: Ihor Radchenko To: Orm Finnendahl Cc: emacs-orgmode@gnu.org Subject: Re: multipage html output In-Reply-To: References: <875xtmd9nz.fsf@christianmoe.com> <87msmypwfw.fsf@localhost> <87zfqxpeog.fsf@localhost> Date: Thu, 04 Jul 2024 16:20:29 +0000 Message-ID: <87sewp9liq.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.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, 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.61 X-Spam-Score: -6.61 X-Migadu-Queue-Id: 7F3ADAEB4 X-Migadu-Scanner: mx11.migadu.com X-TUID: puhNRZUQstLM Orm Finnendahl writes: > Sure. I'm not at all familiar with the peculiarities of other output > backends, but see your point. If you can give any hints or have any > ideas *how* we could find general rules for separating the subtrees, > which cover foreseeable use cases, or devise a flexible mechanism for > doing so, I'd be glad to help setting them up and implementing them. I > definitely agree, the code should be as general as possible while > providing complete backward compatibility. I think that the easiest would be adding a new option to `org-export-options-alist' - it is already extendable for individual backends and allows users to tweak things via in-buffer keywords, properties, variables, and export options. The most generic rule would be some kind of function that takes AST node as input and returns whether that node should be going to a separate file or not, and if yes, tell (1) which export backend to use to export that subtree to a file (may as well allow exporting to different formats, while we are at it); (2) what are the export parameters to be used for that export, (possibly) including the file path. Then, in addition to the most generic (and most flexible) "rule being an Elisp function", we can allow some simplified semantics to define rules. The semantics should probably give a couple of toggles to customize: (1) which subtrees are selected for export; (2) which export backend is used (3) how their file names are generated; (4) (optional) how they are represented when exporting the whole original file; e.g. whether to put links to exported files in place of their subtrees; (5) (optional) how the original file is represented in the exported subtrees; e.g. whether to put backlink to parent file The subtree selection may boil down to the usual TAGS matcher (or function), as described in "11.3.3 Matching tags and properties" section of the manual. This will cover the previously discussed separation based on headline level, a tag, or a property. The export backend selection may be realized by allowing multiple rules with each rule defining selection/backend/file name/.... In terms of the value semantics in Elisp, I am thinking about something re-using backend definition format: (setq org-export-pages '(:selector "LEVEL=3D2+blog+TODO=3DDONE" :backend html ;; completely remove the exported subtree is original document ;; is being exported. :page-transcoder nil ;; or :page-transcoder #'org-export-page-as-heading-with-link :export-file-name "%{TITLE}-%{page-number}" ;; or some other kind o= f template syntax ) '(:selector a-function-accepting-ast-node :source-backend any=20 :backend (:parent html ;; `org-export-define-derived-backend'-like semantics :options-alist ;; Do not export private headings in HTML pages. ((:exclude-tags "EXCLUDE_TAGS" nil (cons "private" org-export-exc= lude-tags) split)))) '(:selector "+export_ascii_page" :source-backend html ; only use this rule when exporting to html :backend (:parent ascii ((template . (lambda (contents info) (format "Paged out from %s\n%s" (plist-get ;; INFO channel for parent document (plist-get info :page-source) :title) (org-ascii-template contents info))))))))) >> 2. Some backends, as you proposed, may target multipage export from the >> very beginning. So, we need to provide some way for the backend (in >> org-export-define*-backend) to specify that it wants to split the >> original parse tree. I imagine some kind of option with default >> values configured via backend, but optionally overwritten by user >> settings/in-buffer keywords. > > I'll look into that and maybe I can come up with something. I was > hesitant to propose anything as I tried to stay as limited as possible > and not get too deep into changing things. If you have suggestions, > please let me know. One way could be simply adding an option like :selector above to the backend definition. Then, it will be used as default selector: (setq org-export-pages (:selector default :backend html) ; export pages to html with default sel= ector ) or even (setq org-export-pages (:backend html) ; export pages to html with default selector ) or just ;; export using the same target backend as selected in the export menu (setq org-export-pages t) ;; (setq org-export-pages nil) - existing single page export ;; (setq org-export-pages 'only-pages) - only export pages, ignore original= file >> 3. Your suggestion to add a new export option for splitting based on >> headline level is one idea. >>=20 >> Another idea is to split out subtrees with :EXPORT_FILE_NAME: >> property. > > I'm not sure I fully understand what you mean: Do you mean specifying > different :EXPORT_FILE_NAME: properties throughout the same document > and then export accordingly? Yes. It is re-using the existing idea with subtree export 13.2 Export Settings =E2=80=98EXPORT_FILE_NAME=E2=80=99 The name of the output file to be generated. Otherwise, Org generates the file name based on the buffer name and the extension based on the backend format. If a subtree has that property set, it is used as output file name. Since there is usually no reason to set this property unless you also want to export subtree to individual file, it makes sense to use this as selector for what to export as pages. Example: #+TITLE: Index document * Emacs notes ** Emacs blog post #1 :PROPERTIES: :EXPORT_FILE_NAME: my-first-post :END: ... ** Fleeting note at [2024-06-20 Thu 22:16] Some notes, no need to export them. * Personal notes ** Personal blog post #1 :PROPERTIES: :EXPORT_FILE_NAME: private/personal-post-trial :END: ... >> 6. I can see people flipping between exporting the whole document and >> multipage document. We probably need some kind of easy switch in M-x >> org-export-dispatch to choose how to export. > > Sure, that is the disadvantage of my proposal to make everything a > "multipage" document. Another disadvantage is that when the user > chooses to open the final document or display it in a buffer the user > can't choose whether to only open/display one page or every exported > page. In most circumstances it should be advisable to just > open/display the first page. We can also just add a switch between > single-page and multipage, with multipage always just exporting to > file, but that also has disadvantages. What to open is a minor detail, really. It can be worked out any moment we need to. The most sensible default, IMHO, it to open dired with the containing directory with all the exported pages. > As the code I proposed is encapsulated in the html backend and not > spreading all over the place, I will now first go ahead to finalize > the existing code to a fully working setup. ASFAICT adapting that to > other needs shouldn't require a complete rewrite. And I might be > around for a while ;-) I advice against doing this. While reading your code, I saw that you used some html-specific functions for modifications in ox.el. If you start by modifying ox.el in Org git repo directly, simply doing "make compile" will warn about instances of using functions not defined in ox.el. Another advantage of editing the ox.el and using Org repository is that you can run "make test" any time and see if you managed to break Org :) --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at