From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Rasmus <rasmus@gmx.us>
Cc: emacs-orgmode@gnu.org, alantyree@gmail.com
Subject: Re: [patch, ox] Unnumbered headlines
Date: Fri, 03 Oct 2014 09:56:55 +0200 [thread overview]
Message-ID: <87iok1twl4.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87lhp0iusr.fsf@pank.eu> (rasmus@gmx.us's message of "Wed, 01 Oct 2014 00:54:12 +0200")
Hello,
Rasmus <rasmus@gmx.us> writes:
> Alan did some testing on a slightly older version of this patch and he
> managed to publish his book without errors and with working links. So
> let's give it another shot.
>
> I briefly tested the output of LaTeX, html, texinfo, odt, md, and
> plaintext and made sure links work and that the right text is shown in
> the output.
Thanks. It looks mostly good. Some minor comments follow.
>> I think the following is more in the spirit of the code (you don't
>> ignore :custom-id property):
>>
>> (ids (delq nil
>> (list (org-element-property :CUSTOM_ID headline)
>> (org-export-get-headline-id headline info)
>> (org-element-property :ID headline))))
>> (preferred-id (car ids))
>
> But we are not checking that :CUSTOM_ID is unique.
This is not our problem, but user's.
> In ox-latex you're required to turn on a variable on to get this
> behavior (I could be mistaken here). For now I have done as you
> suggest. But I don't understand why we are favoring CUSTOM_ID here
> over the nice, unique label we've generated?
We could do the same as ox-latex, default to generated label, and
optionally allow users to use raw custom-id instead (with usual caveat).
Meanwhile, I think it is reasonable to stick to the current behaviour.
>> Last line:
>>
>> (list headline (incf num))
>
> Oh incf is quite handy. Didn't know that one.
>
> I leave it as (cons headline (list (incf num))). Why? 'Cause that's
> the format used by `org-export--collect-headline-numbering'. While
> simpler is nicer, I think it's better not to have to consider
> different data structures depending on whether data is from
> `org-export--collect-headline-numbering' or
> `org-export--collect-unnumbered-headline-id'.
I don't get your point. (cons 'a (list 'b)) is equivalent to (list 'a
'b). Why do you think this changes the data structure?
>> (unless (org-some
>> (lambda (h) (org-not-nil (org-element-property :UNNUMBERED h)))
>> (org-export-get-genealogy headline))
>> ...)
>
> Handy. AFAIK BLOB is not a member of (org-export-get-genealogy BLOB)
> (or so the output suggests), so (or · ·) is still needed.
I think
(org-some (lambda (h) ...)
(cons headline (org-export-get-genealogy headline)))
is more elegant.
> + ;; headline linked via CUSTOM_ID
;; Headline linked via CUSTOM_ID.
> + (or (and (string= type "custom-id")
> + (org-element-property :CUSTOM_ID destination))
> + (org-export-get-headline-id destination info)
> + (t (error "Shouldn't reach here"))))
> ;; What description to use?
> (desc
> ;; Case 1: Headline is numbered and LINK has no
> @@ -3073,13 +3063,16 @@ holding contextual information."
> (let* ((class-num (+ (org-export-get-relative-level parent info)
> (1- (plist-get info :html-toplevel-hlevel))))
> (section-number
> - (mapconcat
> - 'number-to-string
> - (org-export-get-headline-number parent info) "-")))
> + (and (org-export-numbered-headline-p parent info)
> + (mapconcat
> + 'number-to-string
Nitpick: #'number-to-string
> + ;; Test if destination is a numbered headline
Missing full stop.
> + (let ((num 0))
> + (org-element-map data 'headline
> + (lambda (headline)
> + (unless (org-export-numbered-headline-p headline options)
> + (cons headline (list (incf num))))))))
See above.
> + (unless
> + (or (org-element-property :UNNUMBERED headline)
> + (org-some (lambda (head) (org-not-nil (org-element-property :UNNUMBERED head)))
> + (org-export-get-genealogy headline)))
> + (let ((sec-num (plist-get info :section-numbers))
> + (level (org-export-get-relative-level headline info)))
> + (if (wholenump sec-num) (<= level sec-num) sec-num))))
Per above
(unless (org-some
(lambda (h) (org-not-nil (org-element-property :UNNUMBERED h)))
(cons headline (org-export-get-genealogy headline)))
...)
> +(ert-deftest test-org-export/org-export-get-headline-id ()
> + "Test `org-export-get-headline-id' specifications."
> + (should
> + (equal "sec-1"
> + (org-test-with-parsed-data "* Headline"
> + (org-export-get-headline-id
> + (org-element-map tree 'headline 'identity info t)
> + info))))
> + (should
> + (equal "unnumbered-1"
> + (org-test-with-parsed-data "* Headline\n:PROPERTIES:\n:UNNUMBERED: t\n:END:"
> + (org-export-get-headline-id
> + (org-element-map tree 'headline 'identity info t)
> + info))))
> + (should
> + (equal "unnumbered-1"
> + (org-test-with-parsed-data "* Headline\n#+OPTIONS: num:nil"
> + (org-export-get-headline-id
> + (org-element-map tree 'headline 'identity info t)
> + info)))))
I suggest to also test tricky inherited UNNUMBERED properties
* H
:PROPERTIES:
:UNNUMBERED: t
:END:
** H2
:PROPERTIES:
:UNNUMBERED: nil
:END:
*** H3
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2014-10-03 7:56 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
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 [this message]
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=87iok1twl4.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=alantyree@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=rasmus@gmx.us \
/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).