Skip to content

Conversation

@helins
Copy link
Contributor

@helins helins commented Sep 28, 2022

Little cosmetics changes for a better behavior with the Github markdown renderer and making large docs easier to navigate.

Previously, the link to the source of a var was in a `<sub></sub>` at
the end of the var description. However, it did not always play nicely
with the Github markdown renderer. For instance, when the last thing in
a docstring was a markdown table, that link would appear as a row.

This commit solves that kind of issues by moving the link to an emoji
right next to the var name. It also declutters the rendered page and
make var names more striking.
Making navigation easier when there are several namespaces on the
rendered page.
@borkdude
Copy link
Owner

I noticed in the previous PR that there are now two different permalinks/anchors for each var.

With this PR I'm noticing that when clicking on the anchor, I see:

https://github.com/babashka/fs/blob/fs-quickdoc/API.md#page_facing_up-expand-home

Is the page_facing_up in the URL an accident?

@helins
Copy link
Contributor Author

helins commented Sep 28, 2022

Those ones are generated automatically by Github based on what's after ##. It's a pity it picks up the emoji ("page_facing_up") though.

However, it was necessary producing anchors that actually take into account the namespace and the name of a var. Those Github anchors based solely on the name wouldn't allow for var links across namespaces. Also, if 2 namespaces were sharing a 2 vars with the same name, GIthub anchors would clash anyways.

All other links are correct. TOC and var links use the nicely generated anchors namespace/name.

@borkdude
Copy link
Owner

Also, if 2 namespaces were sharing a 2 vars with the same name, GIthub anchors would clash anyways.

quickdoc solves this already, by numbering those

Those ones are generated automatically by Github based on what's after ##

Maybe we could just not use ## then and use the one we generate?

@helins
Copy link
Contributor Author

helins commented Sep 29, 2022

I wasn't really sure the numbering was solving that because that means the var name would have been numbered in the ##. If my understanding is correct 🤔

Github anchors are generated for all #... headings so we would have to find another good way of making var names stand out. I'll give it a go when I find a moment 👍

BTW, those Github anchors are not ideal but they aren't that problematic since all other links in the document don't use them. But yeah, let's try to avoid them.

@borkdude
Copy link
Owner

I think people will use those links to refer to vars from other places, so it would be best to avoid having to maintain multiple things.

@borkdude
Copy link
Owner

I'll go ahead and merge this so we can do the next thing as a smaller PR

@borkdude borkdude merged commit fc5a18b into borkdude:main Sep 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants