![]() ![]() So, that would be one reason why "this working ToC cannot be rendered as GFM in some fashion". Even if Typora did have an option to generate or update an embedded table of contents, I would want it to be a manual step or command, not something that was altered automatically while I might be (say) making edits to a file that's part of some other person's project I've checked out of Github. Some of us users are worried about how much Typora already takes upon itself to alter the contents of our files without our knowledge or consent. (And please forgive the theatrics - I just wanted to try and make this clear) Typora said, "Here's a working ToC Loser User - but you can't have it! Ha ha ha!" What I don't understand is why this working ToC cannot be rendered by Typora as GFM in some fashion so that it can be copied-and-pasted into my *.md file. Consequently, I cannot upload a *.md file with the tag, and have the ToC rendered. I understand that the document itself contains only a tag (visible when viewed in source mode), and that the tag isn't supported by GitHub, etc. While using Typora, selecting Table of Contents from the Paragraph menu item instantly generates a great-looking ToC! It's a working ToC in that I can click an element in the ToC, and the display adjusts to show the correct section of the document in Typora. I need/want an automated way to generate & update a ToC in my *.md files.Many files in my repos benefit hugely from a table of contents.I use Typora primarily for creating content in my GitHub repos (i.e.I use Typora for ~ 2 years now & like it!.those options are important.Ĭolor me dumb, but I'm horribly confused by all of this. If you really want something that is purely defined with symbols, maybe mixing the table syntax with could work well across the board, but this would assume there is only one type of TOC you would want injected with no not sure how you would take that and make it work for a flexible TOC, which could be generated to a specific heading depth, including figures or not, etc. It conflicts with at-mentions in GFM, but those only apply to issues, comments, etc., and not to actual markdown files, so I'm ok with that. That said, in a tool I manage, we were looking at using for the replacement, or something similar, because we overload for text we want replaced, not styled. Adoption and use of markdown may be pushing it beyond it's original goals, where symbols may not be enough to define document styling, and that's not necessarily a bad thing, as long as it's properly managed/planned. Do the people driving the CommonMark standard consider not only which symbols are used when, but which international keyboards provide easy access to those symbols, and which do not? Internationalization is very hard, and maybe too idealistic for what is essentially a markup language. ![]() While I appreciate Markdown and CommonMark's decision to avoid the use of any predefined strings of English text, I think there are cases where it is justified. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |