Re: Do not inherit unnumbered property: help needed

[Kaushal Modi <kaushal.modi@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3668 bytes --]

On Fri, Nov 17, 2017, 7:00 AM Akater <nuclearspace@gmail.com> 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

[-- Attachment #2: Type: text/html, Size: 6473 bytes --]