Navigating from TOC to chapters, navigation skipping chapters

[heikkil]

I am having the same problem as in #13 with some additional features. In all epub files I have tried, I can not enter the chapter with enter. The only way I could see something else than the TOC, is to press 'N'.

You can try this book https://www.gutenberg.org/ebooks/1342 . Both epub versions available (with or without images) cause emacs to complain of the same thing. In addition, first press of 'N' shows the toc with header text and next 'N' shows chapter 7. Consecutive presses of 'N' jump to chapters 11, 17, 20, 25, 30, 35, 40, ...

[wasamasa]

I cannot repro the first issue. What Emacs version and OS are you using? How did you install the package and are you on the latest version?

The second issue isn't something I can do anything about, that's just how the book has been authored. Perhaps the command shouldn't be named nov-next-chapter, but rather nov-next-document as it jumps to the next HTML document. Your EPUB has several chapters in one document, that's why you can jump from the first to the seventh with one key.

[xiongtx]

Perhaps the command shouldn't be named nov-next-chapter, but rather nov-next-document

Agreed, since apparently there can be more than one chapter in a document.

[heikkil]

This is under OSX:
GNU Emacs 25.2.1 (x86_64-apple-darwin16.7.0, NS appkit-1504.83 Version 10.12.6 (Build 16G29)) of 2017-09-02

Installed with homebrew:
brew install emacs --with-modules --with-cocoa --with-gnutls --with-librsvg --with-mailutils --with-imagemagick@6

[wasamasa]

@xiongtx I've renamed the commands.

@heikkil Please check whether you still get this issue with the latest commit, it should be included in the latest MELPA and MELPA Stable releases, too.

[heikkil]

Navigation from TOC now works as expected.

The renamed commands work as well, although I would argue that renaming commands to reflect the the nonintuitive way they work is not the right solution. All epub readers I've used have navigation paradigm that work by chapters. Documents are implementation level details that should not be visible to the user.

I'd prefer to see emacs buffer content to correspond to book chapters regardless to physical structure of book and reinstatement of old names (and key bindings). Maybe chapter view could be implemented using narrowing in cases when there are multiple chapters in a document.

I am not too familiar with the variation in epub XML, but at least Project Gutenberg books have TOC at the beginning of the first document, so parsing and using that information should not be too hard.

[xiongtx]

I'd prefer to see emacs buffer content to correspond to book chapters regardless to physical structure of book

I'm in favor of this as well. Seems like the convention is to put a single chapter in a document, but it doesn't have to be the case.

[wasamasa]

I'm closing this as the original problems have been solved.

As stated in #11 chapters aren't a thing in EPUB (instead you get navigation structures for jumping to a point in a document) and slicing things based on the TOC structure is something that can go horribly wrong. Consider these two examples of TOCs:

• Foreword (file1.html)
• Chapter 1 (file2.html)
• Chapter 2 (file2.html)
• Chapter 3 (file3.html)

vs

• Foreword (file1.html)
• Chapter 1 (file2.html)
  • Section 1 (file2.html)
  • Section 2 (file2.html)
  • Section 3 (file2.html)
• Chapter 2 (file3.html)
  • Section 1 (file3.html)
  • Section 2 (file3.html)
  • Section 3 (file3.html)

Sure, for a human it's easy to see that you'd want to put everything labeled "Chapter \d" into one buffer, but for a program it isn't without extra guidance. If you do it based on files, you could see extra chapters for each document (what's currently done), if you slice on each toc item, you could get too granular snips (the info way and what I've opposed doing in the linked thing). What I could imagine working out is an extra command that takes where you currently are, looks it up in this tree and navigates you to the next tree item. The difference with this approach is that it doesn't attempt to visually separate that content from any other (and would for that reason not really make sense for me to have), but if you're fine with that...