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