From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Rasmus <rasmus@gmx.us>
Cc: emacs-orgmode@gnu.org, alantyree@gmail.com, tsd@tsdye.com
Subject: Re: [patch, ox] Unnumbered headlines
Date: Mon, 11 Aug 2014 16:18:08 +0200 [thread overview]
Message-ID: <87bnrrp0tb.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87lhqzyubg.fsf@gmx.us> (rasmus@gmx.us's message of "Fri, 08 Aug 2014 15:39:15 +0200")
Hello,
Rasmus <rasmus@gmx.us> writes:
> In a recent thread¹ Tom and Alan mention that authors sometimes need
> unnumbered headlines, e.g. for prefaces. This patch (tries to) add
> this feature via the tag :nonumber: (customizable via Custom or
> in-file).
Interesting. Some comments follow.
> I make two assumptions. First, the tag is recursive, so if the parent
> is not numbered the child is not numbered.
Indeed.
> Secondly, I depart from the LaTeX tradition of ignoring unnumbered
> headlines in the TOC (except in the case of ox-latex.el where it
> depends on org-latex-classes). (See example below).
OK.
> In my opinion a :nonumber: tag is a natural continuation of :export:
> and :noexport:
First, maybe a tag is not the best way to specify it. Tags are rather
obnoxious and their length is somewhat limited by the width of the
window.
Another option is to use properties, e.g. "UNNUMBERED", or "NO_NUMBER"
with a non-nil value
* Some headline
:PROPERTIES:
:UNNUMBERED: t
:END:
It is harder to notice an unnumbered headline, but it doesn't add cruft
to the tag line, and this is far less important than :noexport:. This is
not perfect either, but I think the trade-off is honest.
Another advantage is inheritance is already implemented for node
properties (see `org-export-get-node-property').
> and unlike :ignoreheading: the implementation is fairly clean (or
> maybe I'm cheating myself here).
Do not underestimate it: implementing this feature is a bit tricky, and
will introduce backward incompatible changes to export back-ends
(possibly outside the scope of core+contrib).
A major problem comes from `org-export-get-headline-number', which
always returns a unique non-nil value for headlines in a parse tree.
Even unnumbered headlines (e.g. with option num:2) get a number.
Consequently, some back-ends use this number as a unique ID, as this
excerpt from "ox-html.el"
(format "<span class=\"section-number-%d\">%s</span> "
level
(mapconcat #'number-to-string numbers "."))
It is not possible to rely on this mechanism with your patch.
A solution is to create two functions for the two features:
- `org-export-get-headline-number' :: the same as today, but returns
nil if headline is unnumbered.
- `org-export-get-headline-id' :: returns a unique ID, as an integer,
for the current headline, notwithstanding its numbering status.
Then `org-export-get-ordinal' should probably try to call the first one
and fallback to the second one.
The previous snippet from "ox-html.el" would become
(format "<span class=\"section-number-%d\">%d</span> "
level
(org-export-get-headline-id headline info))
Obviously, this implies that every back-end using this construct should
be updated accordingly.
WDYT?
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2014-08-11 14:17 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-08 13:39 [patch, ox] Unnumbered headlines Rasmus
2014-08-08 22:35 ` Alan L Tyree
2014-08-09 1:04 ` [patch, ox] Unnumbered headlines - early test Alan L Tyree
2014-08-09 7:47 ` [patch, ox] Unnumbered headlines Detlef Steuer
2014-08-11 14:18 ` Nicolas Goaziou [this message]
2014-08-11 15:37 ` Rasmus
2014-08-12 8:58 ` Nicolas Goaziou
2014-09-20 16:02 ` Rasmus
2014-09-20 20:34 ` Alan L Tyree
2014-09-21 13:12 ` Nicolas Goaziou
2014-09-21 14:37 ` Rasmus
2014-09-21 19:40 ` Nicolas Goaziou
2014-09-21 20:13 ` Rasmus
2014-09-22 15:53 ` Nicolas Goaziou
2014-09-23 0:35 ` Rasmus
2014-09-23 1:10 ` Thomas S. Dye
2014-09-26 7:51 ` Nicolas Goaziou
2014-09-26 13:48 ` Rasmus
2014-09-27 8:19 ` Nicolas Goaziou
2014-09-30 22:54 ` Rasmus
2014-10-02 0:35 ` Rasmus
2014-10-03 7:56 ` Nicolas Goaziou
2014-10-03 8:49 ` Sebastien Vauban
2014-10-03 10:26 ` Rasmus
2014-10-03 20:14 ` Nicolas Goaziou
2014-10-03 20:31 ` Rasmus
2014-10-05 8:06 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bnrrp0tb.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=alantyree@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=rasmus@gmx.us \
--cc=tsd@tsdye.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).