Add anchors and spacing #16
Conversation
Applies to asciidocHandleTitle(), prepending any headline text with a "slug" wrapped in `[[ * ]]`. * Forces lowercase * Replaces spaces with hyphens Case and hyphenation changes are not required, but they tidy up the anchors.
|
I think this features should be configurable. AFAIK we can create a custom dialog and use Property service to store and serve data. |
|
Yeah, I thought of that as well. In some cases I would find the anchors superfluous, though the s&r regex stripping them is simpler than adding them ;-) We could also consider allowing such alterations inside the modal after the main conversion takes place. It might be nice to do this for certain types of cleanup that I've had to do post-migration, that maybe were due more to the way my docs were formatted than the script itself. But I think re-running the "server-side" conversion is easy enough, so you could just toggle those options as needed. I don't know how trivial it is to add these features. This is my first contrib to a Google Apps project. I'm definitely in, though. I need this tool ;-) |
This is my first Google Apps project too 😄
Why not but a configuration panel will avoid to re-running the conversion. |
|
+1 for sure. I think you're right about the approach. Count me in for several hours of tinkering and testing. One other configurable preference I would use is converting headings to |
|
We can hold this branch off until we slip those conditionals in, no worries. The add-on testing in GDocs is relatively easy to use for production. |
|
@briandominick Do we really need to explicitly define anchors ? You could add
I think @mojavelinux will disagree on this one 😉 If we decide to not include this feature, then creating a configuration panel, to choose to add an extra space or not, is not worth it I guess. However I've started experimenting on a configuration panel and it's quite easy so feel free to add more features 😄 |
|
@Mogztter So this is funny: it was only this weekend that I realized I do think explicit anchors can be useful. I got the idea of forcing them from another converter; I don't recall which. I think what I like about them is they can stay the same even if the heading they mark gets changed, so you don't get broken links and xrefs. I'm not really sure if that's best practice for team usage. I've had the luxury(?) of being the only one directly using my AsciiDoc files until now. I don't think it's the end of the world at all to not offer this, but it seems simple. This script is incomplete, though -- it needs more replacements, such as Good to know config is easy. I'll draft off your achievement when you commit the first one ;-) |
|
@Mogztter anticipated correctly, I also prefer generating the document using As for the section anchors, I think we're getting section IDs and anchors confused. The If you want to see a physical anchor or link, then you must set either the For mature documents, it's a good idea to set the ID explicitly for reasons @briandominick explained. So I do think it is a good option to have. The auto-generated ID is to save typing in early drafts and for simpler documents. If we set auto-generated IDs, however, we should use the modern syntax. |
|
+1 to generating IDs, not anchors, formatted as: |
A couple little changes in these commits.
One just improves (I think) spacing around code listings.
The other prepends anchor slugs to every heading. I've found other tools doing this, and some output processors don't add anchors later, including jekyll-asciidoc. I hope it's useful!