From mboxrd@z Thu Jan 1 00:00:00 1970 From: Akater Subject: Do not inherit unnumbered property: help needed Date: Fri, 17 Nov 2017 11:56:27 +0000 Message-ID: <87375dazkk.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFfJ3-0002nW-9B for emacs-orgmode@gnu.org; Fri, 17 Nov 2017 06:59:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eFfJ0-0001CG-6K for emacs-orgmode@gnu.org; Fri, 17 Nov 2017 06:59:37 -0500 Received: from mail-wm0-x232.google.com ([2a00:1450:400c:c09::232]:41070) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eFfIz-0001BV-V9 for emacs-orgmode@gnu.org; Fri, 17 Nov 2017 06:59:34 -0500 Received: by mail-wm0-x232.google.com with SMTP id b189so5999222wmd.0 for ; Fri, 17 Nov 2017 03:59:33 -0800 (PST) Received: from localhost (exit02.brasshorncomms.uk. [185.104.120.2]) by smtp.googlemail.com with ESMTPSA id i32sm2563325eda.36.2017.11.17.03.59.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 03:59:31 -0800 (PST) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org --=-=-= Content-Type: text/plain I have to deal with a document that has an unfortunate vague structure which involves unnumbered headlines spanning a couple of numbered ones. I'd like to convert the document into Org and thus effectively need to implement a feature that would allow unnumbered property in Org not to be inherited by children of unnumbered items in some cases. Say, in the following toy example #+BEGIN_SRC org * section-one-title blah * the first two prime-numbered sections (duh) :properties: :ignore-this-outline-level: t :unnumbered: t :end: ** section-two-title blah ** section-three-title blah * section-four-title blah #+END_SRC section-three and section-four would be treated as being on the same level as other section-x's, their children treated correspondingly. For exporting needs, I chose to format the unnumbered headline the same style as section-x's, only unnumbered, and have section-two and section-three be numbered as if the unnumbered headline didn't exist. First, I need to mark (?) parts of the parse tree that are children of the unnumbered item, and are not explicitly marked unnumbered themselves, as exportable when being passed to org-export--collect-headline-numbering. This is where I ask for help, as it's not clear to me how to do that. My hypothesis so far was that org-export--prune-tree from ox.el filters out unnumbered items but my attempts with debug-on-entry did not confirm this. Could someone help? Re: (?) maybe children are never marked as exportable in the first place and the tree just does not get traversd too deep. Again, I don't yet see which function is to be patched to let them through. Second, I will also need to redefine specialized functions like org-html-section, turning org-export-get-headline-number into org-export-get-deepest-numbered-parent-headline-number and so on, but this doesn't seem to be difficult. However, if I'm missing something and you think this could be a valuable feature, you are welcome to share your thoughts. I'm not an experienced programmer but hopefully I can implement this and contribute. n(Will sign anything FSF if needed.) I admit that the whole idea to add this to Org is questionable, and documents structured like this better be restructured altogether. It is likely that exported versions for some backends are not going to be structured properly. (As far as I can see, Texinfo looks particularly unpromising.) Nevertheless, it is possible to at least make exported versions /look/ ok and describe possible backend-related caveats in the documentation. I find it reasonable to keep org files structured properly, while considering exported versions to be more of an eye candy. In my case, the document in question is an archive entry which cannot be changed retrospectively but me and my colleagues could still benefit from it being tidily marked up. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJaDs5zAAoJELK+sWGx7H9EfwEP+wXHDWbCkixU2lfcR94cll5e HDjUQzRRgzAO1AgySKUwjk8nnGmUoEh/Cbb8oo2iD2+QMMhZHlBLrPQVKHOY1Q11 fj95dkCgP++yPis075wOggiqlJGsi++zO/cw8vFNBQezQGLozuqb78tR+PknJGqZ MkoqYafRNlw5Hejq8rjb2e16KpHX8RHHv3YKHp+QPrYV5aJcbmUI7h3eO0nAQ6z2 Dqe02d+0fClFDw5eGtI9NmKzG4BTFNkwBMVtk8qacJn4NNcFUTyuesbS2q6jJ76P 9nw8tgQwHTN9oxep6CKqgfKkTSvNE9zO0t1Ht/JJJEa5v5bxLSAWf/YPhUox6VHR /lwRG0sQhf7JZRkrukA9+C2Y6rdlvjUBrdvdJTFb+PU6UwjQxG597eBwC2eVi12X DfV+ysVEWRd9ZI8HfEkFC7+G7etzWmNUG5tUWqj0qba7GvfruHHQZlCb/6q3ochV p9CrRr7/iKzF5D8tixbtfRAN+0pPQw5ACnOZXNMrHfhmbEQthwOxPkgX9nMexl19 ZgLbLUrLXzXNGZqHzWDgL3113SCdlqVvnsJGVWwuxAzWUurMKkd33QwrbrdEhllR 1jWkN+sJ3OgmP6U7Fkl2UrDvScUS0tr7bUArkybkMXpiMTOpyKCOZ5gCrv8BSWRx vaVl2r23q3uJ4NtEPRQx =6DJt -----END PGP SIGNATURE----- --=-=-=--