From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kaushal Modi Subject: Re: Do not inherit unnumbered property: help needed Date: Fri, 17 Nov 2017 12:21:21 +0000 Message-ID: References: <87375dazkk.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114faab0ecf04d055e2cc6ff" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eFfeJ-0001ed-6E for emacs-orgmode@gnu.org; Fri, 17 Nov 2017 07:21:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eFfeH-00058d-Kk for emacs-orgmode@gnu.org; Fri, 17 Nov 2017 07:21:35 -0500 Received: from mail-yw0-x233.google.com ([2607:f8b0:4002:c05::233]:39751) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eFfeH-00058H-EK for emacs-orgmode@gnu.org; Fri, 17 Nov 2017 07:21:33 -0500 Received: by mail-yw0-x233.google.com with SMTP id g204so1173954ywa.6 for ; Fri, 17 Nov 2017 04:21:33 -0800 (PST) In-Reply-To: <87375dazkk.fsf@gmail.com> 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: Akater Cc: emacs-org list --001a114faab0ecf04d055e2cc6ff Content-Type: text/plain; charset="UTF-8" On Fri, Nov 17, 2017, 7:00 AM Akater wrote: > 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 > Have you looked at org-use-property-inheritance variable http://orgmode.org/manual/Property-inheritance.html -- You can set that to a regexp that does not match UNNUMBERED. section-three and section-four would be treated as being on the same > level as other section-x's, their children treated correspondingly. > That won't be possible unless you define a custom exporter with it's custom property that doctors the level interpreted from the leading stars. For exporting needs, I chose to format the unnumbered headline the > same style as section-x's, only unnumbered, I don't see why that wouldn't be possible. and have section-two and > section-three be numbered as if the unnumbered headline didn't > exist. > That's the default behavior too. 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. > I don't think that is needed. The numbering of the headings after the unnumbered headings stays the same whether or not you export the unnumbered heading. 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. Can you explain more on what features you propose for those functions so that people can comment? I'm not an experienced programmer > but hopefully I can implement this and contribute. > n(Will sign anything FSF if needed.) > Signing FSF as the first step is usually a good thing. So that with the paperwork in place, you can contribute to Org/Emacs whenever you get a chance in future. I admit that the whole idea to add this to Org is questionable, and > documents structured like this better be restructured altogether. I didn't follow that. 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. > I didn't follow all that you mentioned in the end. It's not clear what the document restructuring was about after the initial problem statements. Let's start with resolving the UNNUMBERED property non-inheritance. > -- Kaushal Modi --001a114faab0ecf04d055e2cc6ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 17, 2017, 7:00 AM A= kater <nuclearspace@gmail.com<= /a>> wrote:
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.
=

That won't be possible unless yo= u define a custom exporter with it's custom property that doctors the l= evel interpreted from the leading stars.=C2=A0

For exporting needs, I ch= ose to format the unnumbered headline the
same style as section-x's, only unnumbered,

=
I don't see why that wouldn't be possible.=C2=A0

=C2= =A0and
have section-two and
section-three be numbered as if the unnumbered headline didn't
exist.

That's the default beh= avior too.=C2=A0

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.

I don't think that is needed. The numbering of the headings afte= r the unnumbered headings stays the same whether or not you export the unnu= mbered heading.=C2=A0

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.

C= an you explain more on what features you propose for those functions so tha= t people can comment?

I'm not an experienced programmer
but hopefully I can implement this and contribute.
n(Will sign anything FSF if needed.)

<= div>Signing FSF as the first step is usually a good thing. So that with the= paperwork in place, you can contribute to Org/Emacs whenever you get a cha= nce in future.=C2=A0=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">I admit that the whole idea to add this to Or= g is questionable, and
documents structured like this better be restructured altogether.

I didn't follow that.=C2=A0

=
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.)

?
Neverthe= less, 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.

I didn= 9;t follow all that you mentioned in the end. It's not clear what the d= ocument restructuring was about after the initial problem statements. Let&#= 39;s start with resolving the UNNUMBERED property non-inheritance.=C2=A0
--

Kaushal Modi

--001a114faab0ecf04d055e2cc6ff--