![]() ![]() In many GitHub projects I use batch scripts to clean up all markdown files via pandoc (from GFM to GFM) before commiting. ![]() all of which is not only good for the eye, but also in Git controlled projects, because it reduces diffing nightmares and false positives in status changes.īut right now, this can't be used on GFM docs which make use of Tasks List - else they break up. Pandoc is a great tool for cleaning up markdown source files (especially with -smart -wrap=none -normalize options): you get properly aligned tables, a standard syntax (where multiple syntaxes are possible), normalization of extra whitespaces, etc. you want to gfm -> PDF)? If you are interested in writing a filter or need help on that, you can open a thread on pandoc-discuss, lots of experts there can give you advices and some might even write one for you (don't count on that, however). is it write to or read from GFM, is pandoc markdown only an intermediate format you need (e.g. How it should be done depends on your need, e.g. ![]() So I suggest if it is something you sorely needed right now, you should write a filter to do it. However, another unique feature in pandoc is its filter system. I don't know much about it, but if I were to make such a big change, I would want to do it correctly the second time and incluides as many features which is useful and requires AST changes as possible (so that there's no third time), which only makes the task more daunting. I think the core developers have been thinking about AST changes. So unfortunately any AST change will be a very daunting task: at least all writers and readers and pandoc-type needed to be changed (sometimes involves more things, say, pandoc-citeproc, templates, etc.) I've suggested a similar approach for column/row spans in tables, but they say it won't work. Feel free to correct me if I'm wrong.Īs far as I understand, it seems a fallback would not work. But it is only useful when the limitation is understood.Īgain, some of the points above based on the assumption that it requires AST change. Note that it is not useless even if not fully compatible. So I guess the most urgent "bug fix" is to emphasize what a markdown variants provided by pandoc means. I know that the manual has mentioned its limitation, but perhaps not emphasized enough. But I'm saying given the level of difficulties, the workloads of the core developers, the amount of open issues, the priorities they might have, this is unlikely to happen in the foreseeable future.ġ thing people often mistaken by those markdown variants in pandoc is that it is supposed to be fully compatible (say, markdown_github, markdown_mmd, etc.), and whenever it falls short of that, people kind of think it should be added because pandoc said it supported it. So what I'm suggesting is not it should not happen, I want it happens too. Now, to me this is something much more important and general to have. 1 of the important feature request that involve AST change is column/row span in tables. Now, among all these "AST change" level of feature request (see a list of them by clicking GitHub's label), how many of them are older? or more important? e.g. And if you see the graph in, it certainly is many. It requires a change in all existing writers and readers. If I'm correct, this put the required change into the most difficult category: "AST change". Because pandoc's internal just can't handle that. ![]() in the case of multimarkdown inline footnote, pandoc do not support it, but pandoc's internal surely can handle footnote (inline or not), so in this case adding such extension only requires a change in the markdown parser.īut in this case, if I am not mistaken, it requires an AST change. When pandoc don't have such extenson, then you need to ask, what it takes to add this extension? Is it a document model pandoc already support? e.g. But the premise is pandoc already have that extension. As far as I understand: pandoc's unique feature is to implement different markdown extensions seperately, such that when different extensions turned on/off, those combinations of extensions becomes another markdown variant. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |