Am Mittwoch, dem 22.12.2021 um 10:37 -0800 schrieb Jason Ross:
>
> Thank you for bringing this up. I'd like to discuss this a bit with
> you
> before implementing such a feature.
>
> I'm not sure how an implementation of this would look to the end
> user.
> ConTeXt has the following system:
> https://wiki.contextgarden.net/Command/_section
>
> \part highest level of sectioning
> \chapter level 2
> \section level 3
> \subsection level 4
> \subsubsection level 5
> \subsubsubsection level 6
> \subsubsubsubsection level 7
> \title level 2, unnumbered
> \subject level 3, unnumbered
> \subsubject level 4, unnumbered
> \subsubsubject level 5, unnumbered
> \subsubsubsubject level 6, unnumbered
> \subsubsubsubsubject level 7, unnumbered
>
>
> So there are a couple of questions that need to be answered:
>
> 1. There's no "level 1, unnumbered" sectioning command in ConTeXt.
> How should this be handled?
> 2. How does the user specify which sectioning scheme to use?
>
> Question (1) implies that the user may need to choose their highest
> level to be either a part or a chapter in order to have unnumbered
> level 1 sections. Things start to get complicated if we do that.
I think that the scheme is conventional, and grown up with books and
LaTeX we are accustomed to it. The chapter-title scheme seems to be
from ConTeXt and I don't know the real reason behind this.
For me the part-chapter-section line is the book oriented sectioning
(with or without numbering) as books can have parts, often have
chapters and sometimes sections.
The title-subject line is the magazine oriented line, because articles
in a magazine or essays in a collection only have titles and subjects,
and they are complete units which could be published elsewhere.
(Sometimes I use titles to mark special chapters that don't appear in
the table of contents.)
I don't think that what we do is always logical and consistent in
itself. But it might be a good memory hook to organize different items
such as books with chapters, articles and independent essays collected
in a book.
To get a broader view on this, we should discuss it in the ConTeXt
mailinglist.
I am deploying a production chain with Markdown-Pandoc-ConTeXt in my
organization. AFAIK Pandoc only produces the part-chapter-section line
while the highest level is configurable. So if we ever need a title-
subject scheme we will have to use filters.
> To avoid these questions, I went with the simplest implementation
> possible and just concatenated "sub"*n with either "section" or
> "subject" to create a sectioning command of depth n.
>
> My understanding is that the sectioning commands are flexible enough
> that any desired result in the output pdf can be produced by
> modifying
> the sectioning commands in the preamble. However, if you are using
> existing environments that rely on those specific names you are out
> of
> luck.
>
Yes I think they are flexible enough and I can customize my styles, but
I would prefer to have a solution which can be used with the usual
sectioning of ConTeXt.
My proposal would be
1.) to have a switch for using
(a) the part-chapter-section line or
(b) the title-subject-line on export.
2.) to have a customization for (a) similiar to pandocs "top-level-
division"
> For your purposes, if you need a fix _right now_, consider overriding
> the definition of `org-context--get-headline-command` to something
> like this:
>
> #+begin_src elisp
> (defun org-context--get-headline-command (headline info)
> "Create a headline name with the correct depth.
> HEADLINE is the headline object. INFO is a plist containing
> contextual information."
> (let* ((level (org-export-get-relative-level headline info))
> (numberedp (org-export-numbered-headline-p headline info))
> (hname
> (cond
> ((and (= 1 level) numberedp) "chapter")
> ((= 1 level) "title")
> (t (let ((prefix (apply 'concat (make-list (+ level (-
> 2))
> "sub")))
> (suffix (if numberedp "section" "subject")))
> (concat prefix suffix)))))
> (notoc (org-export-excluded-from-toc-p headline info)))
> (if notoc
> (format "%sNoToc" hname)
> hname)))
> #+end_src
>
>
Thanks a lot. I will try this the next days.
>
>
> This is fixed on the "develop" branch as of today. I missed a
> comma...
Great.
juh
