Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve extract_examples to allow naming files based on the chapter or section number #233

Open
fingolfin opened this issue Oct 29, 2019 · 1 comment

Comments

@fingolfin
Copy link
Member

In AutoDoc 2019.09.04, the extract_examples generates files which are named pkg01.tst, pkg02.tst, etc., in a strictly linear fashion, with one file "per unit", where units without examples are skipped. In commit 573359e I hacked this up so that it doesn't skip empty units, so that if one uses chapters as units, one gets the chapter number in the filename, which IMHO is better.

But as @zickgraf reminded me today, of course one can also use sections as units; and then the new behavior makes little sense.

So, I think it would be much better if we gave the use the choice between the following variants:

  1. number in a strictly linear fashion, without gaps (the current default)
  2. number based on "unit identifiers": so the chapter number; or for sections, use "chapternum.sectionnum". So examples from section 5.4 would end up in a file pkg_5_4.tst (or pkg_5.4.tst, or pkg_chapter_5_section_4.tst, or whatever). Not sure what other unit types we support, but I'd hope we could come up with a good numbering for each.

I guess other variants are possible, but for now, having option 2 would already make me quite happy and I think it'd work out nicely.

@zickgraf
Copy link
Contributor

Not sure what other unit types we support, but I'd hope we could come up with a good numbering for each.

Besides Chapter and Section there are Subsection and Single. For Subsection the numbering should obviously be analogous to the one for Section. For Single there might be multiple reasonable approaches.

Note that a better numbering was already discussed in #197 and deferred as rather complicated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants