Re: [O] Do not inherit unnumbered property: help needed

[Kaushal Modi]

On Fri, Nov 17, 2017, 7:00 AM Akater <address@hidden> 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