So far as I can tell, org-mode currently allows heading numbering in only
one style (1, 1.1, 1.1.1, etc.).  For HTML export, I'm interested in having
the heading numbering be configurable on a per-subtree basis, along
something like the following lines for a hypothetical consulting-agreement
contract  (indentation is for convenient reading only).  This is for my Common
Draft <http://www.CommonDraft.org> contract terms and conditions project
--- I'd like to be able to arrange the trees in an arbitrary order and have
the top-level headings start with prefixes and heading numbers instead of
heading numbers alone.

This can be done in a very kludgy fashion with CSS (see below), but doing
it in org-mode would be far preferable for several reasons.

I'd be happy to pay an honorarium, or make a donation, of USD$100-$200 for
the appropriate elisp code that I could include in the relevant file(s).
I'd want the elisp code to be open-sourced, and at least minimal
documentation, so that it could be made a candidate for possible inclusion
in a future org-mode release.

Here's an example of the desired org-mode code:


===BEGIN===


* Services

  :PROPERTIES:

  :CUSTOM_ID: SVC

  :CUSTOM_PREFIX: t

  :END:
# ======== NOTE THE :CUSTOM_PREFIX: property above =========== #


** Statements of Work

[properties and text omitted]


*** Written Statements of Work Required

[properties and text omitted]
# =========== AN ARBITRARY NUMBER OF SUBHEADING LEVELS BENEATH THE TOP
LEVEL ============= #


*** Changes Must Be in Writing
[properties and text omitted]



** Billing Rates

[properties and text omitted]


** IP Ownership

[properties and text omitted]


* General Provisions

  :PROPERTIES:

  :CUSTOM_ID: GP
  :CUSTOM_PREFIX: t

  :END:


** Amendments

[properties and text omitted]


** Notices

[properties and text omitted]

===END===


I'd like for the resulting HTML export to be something like the following:

SVC Services

# ======== NOTE THAT THERE'S NO HEADING /NUMBER/ FOR THE TOP-LEVEL HEADING,
JUST THE PREFIX ========== #


SVC-1 Statements of Work

[properties and text omitted]

# ======== PREFERABLY THE SEPARATOR IN "SVC-1" COULD BE CONFIGURED AS A
HYPHEN, A PERIOD, A COLON, A FORWARD SLASH, ETC. ============= #


SVC-1.1  Written Statements of Work Required

[properties and text omitted]

SVC-1.2  Changes Must Be in Writing

[properties and text omitted]


SVC-2 Billing Rates

[properties and text omitted]


SVC-3 IP Ownership

[properties and text omitted]


GP General Provisions


GP-1 Amendments

[properties and text omitted]


GP-2 Notices

[properties and text omitted]



I've played with doing this in CSS --- a suboptimal solution would be to:

   1. set the :UNNUMBERED: property to non-nil
   2. define separate CSS div classes for each top-level heading (e.g., SVC
   and GP in the examples above)
   3. for each top-level heading in question:
      1. use the :HTML_CONTAINER_CLASS: property to specify the div class
      for that top-level heading
      2. for each subheading level in that div class, use the
      psuedo-element ":before" to add the appropriate prefix and counter

Apart from being kludgy, doing it this way (in CSS) would eliminate
org-mode's ability to produce automatic cross-referencing during export.
Also, the heading numbers wouldn't transfer over when copying and pasting
from HTML to a Word document, which is an important user feature.

In case it matters, I run the 2016-07-25 release of org-mode on Emacs
25.1.50 (9.0) with the most recent update of Mac OS X El Capitan.  I know a
little about elisp and have cobbled together a few simple functions for my
own use, but I'm far from being even minimally competent at it.

Any ideas for an org-mode elisp solution?

​Thanks in advance,

--D. C.

D. C. Toedt III
*(My last name is pronounced "Tate")*
Attorney & arbitrator -- tech contracts & IP
O: +1 (713) 364-6545   C: +1 (713) 516-8968
​​

dc@toedt.com    @dctoedt <https://twitter.com/DCToedt>
​
Skype: dctoedt
​

www.OnContracts.com/About <http://www.oncontracts.com/About>
​​


Unless expressly stated otherwise,
this message is not intended to serve
as assent to an agreement or other document,
even if attached to this message.