add-file: Add chapter, book and part options - #1007
Conversation
| case "chapter": | ||
| dest_path = se_epub.content_path / "text/chapter-.xhtml" | ||
|
|
||
| _copy_file("chapter-template-add-file.xhtml", dest_path, args.force) | ||
|
|
||
| _replace_languague(dest_path, se_epub.language) | ||
|
|
||
| case "book": | ||
| dest_path = se_epub.content_path / "text/book-.xhtml" | ||
|
|
||
| _copy_file("book-template.xhtml", dest_path, args.force) | ||
|
|
||
| _replace_languague(dest_path, se_epub.language) | ||
|
|
||
| case "part": |
There was a problem hiding this comment.
Do the new options need to be added to the shell completions?
|
Thanks Erin! As Andrew noted, we also need to add shell completions. I don't think it makes sense to add both book and part, because the structures are almost identical. Just part will do and the producer can tweak it to fit. I would also remove The ID should just be part-1. In the chapter, its ID should also just be chapter-1 with no data-parent. |
b4a9ed5 to
a78084b
Compare
|
Thanks Andrew and Alex; sorry I missed that. All the changes mentioned should be there now, as well as two others: the |
|
Great, thanks! |
After reviewing the manual, especially 7.1.5.1, it seemed to make most sense to add both
bookandpartalongsidechapter. I know that it varies quite a lot whichepub:typeis associated withbook: it can be division, part, or even chapter; but the templates are always going to need to be edited further by the producer anyway, so I don't think this undermines the utility of being able to quickly generate the basic skeleton with theadd-filecommand.If you don't think all three of these options are useful, let me know which you want excluded.
Also, contrary to what I said in the issue, it does seem necessary to have a chapter template for this purpose that is distinct from the one used by
split-file. Let me know if you disagree about that, or anything else here, and I'll make the necessary changes.I also noticed a typo in a function name in
add-file.py:_replace_languagueshould be_replace_language. It doesn't affect any functionality because the typo appears throughout. I'll wait until this is merged or closed to fix that in a separate PR.resolves #1006