rust apidocs: splitting is not working

[emmanueltouzery]

For the rust apidocs, if I try to display toplevel docs, like std::vec::Vec for instance, things work, although i think it includes all functions on Vec, too. Now if I look at std::vec::Vec::chunks for instance, it's again the full Vec documentation that is displayed, not the section specific to chunks.

So something is not working with the headers splitting. The markdown conversion in itself looks very good otherwise :+1:

[luckasRanarison]

The reason it didn't work was because the pattern contained multiple lines (it was a code block). I went for a quick fix and just made the search match the first line of the pattern.

However, for the docs with a similar structure, splitting won't be perfect. Since the pattern isn't a header, we can't determine when to stop. The only possible way to fix this would be to gather information about the next section, but that's out of scope.

[emmanueltouzery]

yes, really too bad about not being able to determine where to stop, however with this change it's now really much much better and very much usable (with a git-compiled glow anyway, i'm assuming the released glow would again be way too slow).

So i'll close this and thanks a lot!

[luckasRanarison]

Wait, I just got an idea... A possible workaround would be adding the path of the next and previous entry to each entry. That'd make the index file bigger but that would allow more accurate splitting and next/prev navigation. What do you think about that?

[emmanueltouzery]

i'm not deep enough into the code to really give an informed opinion. splitting at the end would be a definite plus for sure. maybe you can give it a shot and see how much complexity it brings?

[emmanueltouzery]

After looking a bit more at the rust apidocs as they are right now.. yes, the ability to cut after the doc item would be a very large plus I think. It would improve the readability and also display performance of the docs. Even with the git version of glow, there is a little lag due to the large size of the displayed docs. And the lack of clear ending is quite distracting.

If you can't try your idea, I can maybe try, but it'll take some time I'm afraid, before I get time for that.

[luckasRanarison]

No problem, I'm also quite busy at the moment so feel free to do what you want. But I've imagined an approach to the problem.

We could add a reference to the previous and next section in each entry when filling the entries passed to telescope in the get_entries functions, but there's a small problem. The sections are not ordered so we can't just loop and get the next or previous entry. To solve this we'll need to order the sections by indexing each section entry with a number instead of using a plain array of object. So some changes need to be made to the section map returned by the html_to_md function and the index.json structure (order the entries).

Basically, getting a reference to the next entry will solve the problem.