Re: [fossil-users] Pessimism about CommonMark in fossil
On Thu, 2 Oct 2014 16:07:56 +0200 Stephan Beal sgb...@googlemail.com wrote: That was unfortunately a bit optimistic of me (i tend towards pessimism in most estimates ;), for which i apologize. Wiki topics in general are way, way, way down on my list of eventual todos. OK, no problem. I, somehow, thought that teaching Fossil to just render using JS in the browser should not be so hard... Sincerely, Gour -- Not by merely abstaining from work can one achieve freedom from reaction, nor by renunciation alone can one attain perfection. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
On Fri, Oct 3, 2014 at 4:56 PM, Gour g...@atmarama.net wrote: That was unfortunately a bit optimistic of me (i tend towards pessimism in most estimates ;), for which i apologize. Wiki topics in general are way, way, way down on my list of eventual todos. OK, no problem. I, somehow, thought that teaching Fossil to just render using JS in the browser should not be so hard... It can do so already, but... a) it requires the JSON API (which is not on be default) because core fossil will try to parse the wiki pages for you, whereas the JSON API provides an option to serve raw (unparsed) wiki pages. b) the client needs to provide his own JS, set it up in his repo header, etc. c) there isn't currently a mechanism which would allow wiki-generated and such to integrate with that, so it requires a completely custom front-end. The core only knows about one type of wiki like, and would send all generated links to the built-in wiki rendering mechanism. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
On Fri, Oct 3, 2014 at 11:18 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Oct 3, 2014 at 4:56 PM, Gour g...@atmarama.net wrote: OK, no problem. I, somehow, thought that teaching Fossil to just render using JS in the browser should not be so hard... It can do so already, but... ... c) there isn't currently a mechanism which would allow wiki-generated and such to integrate with that, so it requires a completely custom front-end. The core only knows about one type of wiki like, and would send all generated links to the built-in wiki rendering mechanism. It could be as simple as a inbrowser tag that Fossil treats the same as verbatim with the addition of wrapping the raw wiki content with a div class=rawWiki or similar. Maybe Joe's new feature can help with this. Did not have a chance to look at it as my field trip got extended. While some JS would be needed, I think the foundation could be fairly simple: Find the div then feed its content to the user's chosen renderer. The main potential complication being that the contained wiki mark-up might confuse the browser's HTML parser. But, I would think that a mark-up that has a browser-based renderer (JS, Java or other) would already address this issue. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
Note that wiki links are generated in many places, most notably the timeline, and if those links also have to work or the solution is only a partial one. (sent from a mobile device - please excuse brevity, typos, and top-posting) - stephan beal http://wanderinghorse.net On Oct 3, 2014 6:02 PM, Ron W ronw.m...@gmail.com wrote: On Fri, Oct 3, 2014 at 11:18 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Oct 3, 2014 at 4:56 PM, Gour g...@atmarama.net wrote: OK, no problem. I, somehow, thought that teaching Fossil to just render using JS in the browser should not be so hard... It can do so already, but... ... c) there isn't currently a mechanism which would allow wiki-generated and such to integrate with that, so it requires a completely custom front-end. The core only knows about one type of wiki like, and would send all generated links to the built-in wiki rendering mechanism. It could be as simple as a inbrowser tag that Fossil treats the same as verbatim with the addition of wrapping the raw wiki content with a div class=rawWiki or similar. Maybe Joe's new feature can help with this. Did not have a chance to look at it as my field trip got extended. While some JS would be needed, I think the foundation could be fairly simple: Find the div then feed its content to the user's chosen renderer. The main potential complication being that the contained wiki mark-up might confuse the browser's HTML parser. But, I would think that a mark-up that has a browser-based renderer (JS, Java or other) would already address this issue. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
On Fri, Oct 3, 2014 at 2:01 PM, Stephan Beal sgb...@googlemail.com wrote: Note that wiki links are generated in many places, most notably the timeline, and if those links also have to work or the solution is only a partial one. I think an example of what I mean would be helpful. If I go to the New Wiki Page page or Edit Wiki Page page, then put the following as the content: verbatim BEGIN_ASCIIDOC *this* is a sample of *asciidoc* END_ASCIIDOC /verbatim Then when I click any Fossil generated link to that wiki page, Fossil will serve up: BEGIN_ASCIIDOC *this* is a sample of *asciidoc* END_ASCIIDOC Then if I have suitable JS code, it can look for BEGIN_ASCIIDOC and END_ASCIIDOC, then feed everything between those 2 line to asciidoc.js While that works, from a user point of view, it is very kludgy. A step better would be if Fossil could accept something like: wiki t=asciidoc *this* is a sample of *asciidoc* /wiki Then serve up something like: div class=wiki_asciidoc *this* is a sample of *asciidoc* /div This would be less kludgy and maybe even have better/simpler JS code to find the content and feed it to the renderer. I don't know whether this would require a new change to Fossil or if Joe's custom page feature could handle this. And, hopefully, there will be at least 1 way to make this even less kludgy. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
On Sun, 28 Sep 2014 16:48:55 -0400 Trevor tre...@breksta.com wrote: Markdown is versatile, simple format but the multiplicity of standards limits its universality. I hope you can contribute to the making of such a standard. I read a bit about the endeavour to make standard version of Markdown, but here I'd propose (Stephen, do you hear me?) to try add support for rendering AsciiDoc(tor) files which was already discussed in the past? It may be an easier task and AsciiDoc is much richer markup suitable for wider range of documentation. Sincerely, Gour -- As a blazing fire turns firewood to ashes, O Arjuna, so does the fire of knowledge burn to ashes all reactions to material activities. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
i hear you ;), but as i said at the start of this thread, i am ambivalent about which format(s) fossil supports, which may be interpreted as i don't care, as long as someone else implements it ;). That said... If you have suggestions for a generic api for arbitrary wiki parsers/filters for libfossil, i am all ears. :) - stephan Sent from a mobile device, possibly from bed. Please excuse brevity and typos. On Oct 2, 2014 10:47 AM, Gour g...@atmarama.net wrote: On Sun, 28 Sep 2014 16:48:55 -0400 Trevor tre...@breksta.com wrote: Markdown is versatile, simple format but the multiplicity of standards limits its universality. I hope you can contribute to the making of such a standard. I read a bit about the endeavour to make standard version of Markdown, but here I'd propose (Stephen, do you hear me?) to try add support for rendering AsciiDoc(tor) files which was already discussed in the past? It may be an easier task and AsciiDoc is much richer markup suitable for wider range of documentation. Sincerely, Gour -- As a blazing fire turns firewood to ashes, O Arjuna, so does the fire of knowledge burn to ashes all reactions to material activities. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
On Thu, 2 Oct 2014 14:43:50 +0200 Stephan Beal sgb...@googlemail.com wrote: i hear you ;), but as i said at the start of this thread, i am ambivalent about which format(s) fossil supports, which may be interpreted as i don't care, as long as someone else implements it ;). Well, I am thinking along these words of you: If you like, as a repayment for saving me weeks of work writing/debugging another ncurses script binding (by introducing me to termbox), we can try to get one set up for you with Asciidoc. considering few people showed interest for it and assuming it's not too hard 'cause it has to support *only* rendering of Asciidoc(tor) files and no support for it in the tickets etc. That said... If you have suggestions for a generic api for arbitrary wiki parsers/filters for libfossil, i am all ears. :) As I wrote above, no intention for providing general api nor support for arbitrary markups...if rendering Asciidoc(tor) can be done with not too much pain by taking advantage of Asciidoctor.js, then it's fine, otherwise forget about it. Sincerely, Gour -- A person who is not disturbed by the incessant flow of desires — that enter like rivers into the ocean, which is ever being filled but is always still — can alone achieve peace, and not the man who strives to satisfy such desires. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
That was unfortunately a bit optimistic of me (i tend towards pessimism in most estimates ;), for which i apologize. Wiki topics in general are way, way, way down on my list of eventual todos. - stephan Sent from a mobile device, possibly from bed. Please excuse brevity and typos. On Oct 2, 2014 2:56 PM, Gour g...@atmarama.net wrote: On Thu, 2 Oct 2014 14:43:50 +0200 Stephan Beal sgb...@googlemail.com wrote: i hear you ;), but as i said at the start of this thread, i am ambivalent about which format(s) fossil supports, which may be interpreted as i don't care, as long as someone else implements it ;). Well, I am thinking along these words of you: If you like, as a repayment for saving me weeks of work writing/debugging another ncurses script binding (by introducing me to termbox), we can try to get one set up for you with Asciidoc. considering few people showed interest for it and assuming it's not too hard 'cause it has to support *only* rendering of Asciidoc(tor) files and no support for it in the tickets etc. That said... If you have suggestions for a generic api for arbitrary wiki parsers/filters for libfossil, i am all ears. :) As I wrote above, no intention for providing general api nor support for arbitrary markups...if rendering Asciidoc(tor) can be done with not too much pain by taking advantage of Asciidoctor.js, then it's fine, otherwise forget about it. Sincerely, Gour -- A person who is not disturbed by the incessant flow of desires — that enter like rivers into the ocean, which is ever being filled but is always still — can alone achieve peace, and not the man who strives to satisfy such desires. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
On Thu, Oct 2, 2014 at 8:56 AM, Gour g...@atmarama.net wrote: On Thu, 2 Oct 2014 14:43:50 +0200 Stephan Beal sgb...@googlemail.com wrote: That said... If you have suggestions for a generic api for arbitrary wiki parsers/filters for libfossil, i am all ears. :) As I wrote above, no intention for providing general api nor support for arbitrary markups...if rendering Asciidoc(tor) can be done with not too much pain by taking advantage of Asciidoctor.js, then it's fine, otherwise forget about it. Not having looked at how either Fossil Wiki is implemented nor how libsoldout was integrated, I don't know what it would take to create a wiki renderer API for Fossil. If a shim layer was used for libsoldout, then, in theory, variants of that shim layer could created for each renderer. Of course, there would still need to be a way to select which shim to use. As for supporting in-browser wiki rendering, how about adding an option on the New Wiki Page and Edit Wiki Page pages to choose in-browser rendering? Then wrap the raw wiki mark-up with div class=wiki.raw and /div when in-browser rendering is chosen. I suppose a way to specify which wiki mark-up to use would be nice, but I'm not sure what is reasonable. While a drop-down list would be nice, it would require a configuration option. A simple test box would be easy, but then that's vulnerable to user error and other problems. Embedded Document wiki pages (*.wiki files) could also be supported. Either by a blanket in-browser rendering config option or by an alternate file name extension (example: .wikib). Other Embedded Document files could be supported by having a config option to specify the list of file name extensions to allow for pass through like PDF files currently are. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
On Thu, Oct 2, 2014 at 4:53 PM, Ron W ronw.m...@gmail.com wrote: As for supporting in-browser wiki rendering, how about adding an option on the New Wiki Page and Edit Wiki Page pages to choose in-browser rendering? Then wrap the raw wiki mark-up with div class=wiki.raw and /div when in-browser rendering is chosen. That's doable already using the JSON API, but it requires some measure of custom JS coding for one's chosen format. e.g. these sites use custom fossil/JSON front-ends to render Google Code format on the client: http://fossil.wanderinghorse.net/wikis/ I suppose a way to specify which wiki mark-up to use would be nice, but I'm not sure what is reasonable. While a drop-down list would be nice, it would require a configuration option. A simple test box would be easy, but then that's vulnerable to user error and other problems. Wikis support (in the mean time) a mime-type option, so that can be used to determine the renderer (that wasn't available at the time the above sites were created, so they are all or nothing Google Code format). Embedded Document wiki pages (*.wiki files) could also be supported. Either by a blanket in-browser rendering config option or by an alternate file name extension (example: .wikib). Other Embedded Document files could be supported by having a config option to specify the list of file name extensions to allow for pass through like PDF files currently are. If i'm not sorely mistaken, Joe's recently-added ability to create custom pages in th1/tcl will allow this type of thing to be done without any changes to the fossil core. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
On Thu, Oct 2, 2014 at 11:03 AM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 2, 2014 at 4:53 PM, Ron W ronw.m...@gmail.com wrote: As for supporting in-browser wiki rendering, how about adding an option on the New Wiki Page and Edit Wiki Page pages to choose in-browser rendering? Then wrap the raw wiki mark-up with div class=wiki.raw and /div when in-browser rendering is chosen. That's doable already using the JSON API, but it requires some measure of custom JS coding for one's chosen format. e.g. these sites use custom fossil/JSON front-ends to render Google Code format on the client: I had not mentioned that because I think a simpler solution is possible. Though if a generic foundation Javascript could be created to support plugging in (with a bare minimum of additional JS coding needed) the user's choice of browser-side renederers, that could be a good option as well. Wikis support (in the mean time) a mime-type option, so that can be used to determine the renderer (that wasn't available at the time the above sites were created, so they are all or nothing Google Code format). I will look at that when I get back to my office (or home, depending on how long my field trip takes). Embedded Document wiki pages ... Other Embedded Document files ... If i'm not sorely mistaken, Joe's recently-added ability to create custom pages in th1/tcl will allow this type of thing to be done without any changes to the fossil core. Sounds interesting. Again, I will look at this when I have access to any of my Fossil servers. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
On Sun, Sep 28, 2014 at 11:36 AM, Natacha Porté nata...@instinctive.eu wrote: as you might already know, I'm the primary author of libsoldout and its integration into fossil to perform markdown-to-html conversion. If you followed recent news, you might have heard of CommonMark[1], ... Unfortunately, the architecture of the parser makes it extremely difficult to implement CommonMark, probably even more difficult than writing a new parser from scratch. ... In case I'm not wrong, it raises the question of changing the markdown engine integrated in fossil, or purposefully forsake CommonMark support (which might make sense if its adoption ends up not as wide as its authors hope). From a Fossil point of view, a safe subset is highly desirable, much as Fossil's built in wiki engine limits HTML. Given that, what in libsoldout conflicts with CommonMark? Maybe those items can be fixed without breaking the current architecture of libsoldout. Then maybe consider other items in CommonMark not currently implemented. If they are safe and they can be implemented with out breaking the current architecture of libsoldout, then maybe they could be added. ... The main advantage of such an architecture is how easy it is to prove that in actually terminates, and to prove upper bounds on memory usage. When components are loosely coupled, which is the case here, it also makes debugging much easier. I like this. It's worth keeping. The main drawback is that there is no backtracking possible without cheating, and very limited look-ahead without severely tightening the coupling between components. This sounds to me like CommonMark may be too complex for its own good. I remember one of the things touted about wiki markup was that it only needed a dead simple parser. ... Consider for example the following ambiguous Markdown code, which is example 239 of current CommonMark specification: *foo`*` When the leading star is encountered, my parser has to scan for the closing star, and doing so without considering the backtick, since code spans might very well have been disabled. So my parser processes it as an emphasis that happen to contain a backtick. Meanwhile, CommonMark prescribes code spans as having a higher precedence than emphasis, so the example should be parsed as a code span that happens to contain a star. For a wiki markup, this sounds like a poor decision for the design. Thanks for your attention, Natacha Thanks for your analysis and summary. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
A PS to my previous post: Maybe could call the mark up implemented by libsoldout SoldOut, a safe subset of MarkDown / CommonMark. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Pessimism about CommonMark in fossil
Hello, as you might already know, I'm the primary author of libsoldout and its integration into fossil to perform markdown-to-html conversion. If you followed recent news, you might have heard of CommonMark[1], which is an attempt to unify most implementations and extensions of Markdown, by providing a non-ambiguous specification. It's an honorable goal, so it makes sense to try to converge existing implementations towards the new standard. Unfortunately, the architecture of the parser makes it extremely difficult to implement CommonMark, probably even more difficult than writing a new parser from scratch. In the rest of the e-mail I will detail why I think so, in case some of the brilliant minds find a mistake in my reasoning and a way to implement CommonMark easily in fossil. In case I'm not wrong, it raises the question of changing the markdown engine integrated in fossil, or purposefully forsake CommonMark support (which might make sense if its adoption ends up not as wide as its authors hope). Fortunately, there is no rush to take such a decision, as a community we can reasonably to wait and see how CommonMark adoption pans out. [1]: http://commonmark.org/ The heart of the architecture is built around an online parser: the input is considered as an infinite stream of characters, and each component of the parser either consumes input characters or hand over control to another component, with control transfer made in such a way that there is no loop without input character consumption. The main advantage of such an architecture is how easy it is to prove that in actually terminates, and to prove upper bounds on memory usage. When components are loosely coupled, which is the case here, it also makes debugging much easier. The main drawback is that there is no backtracking possible without cheating, and very limited look-ahead without severely tightening the coupling between components. Moreover, when designing the parser, I enforced very loose coupling between component by requiring all language elements to be individually added or removed from the parser. The reason for that is that complete Markdown is extremely powerful, especially because of raw HTML input features. That's too powerful for untrusted input, like blog comments or wikipages. So unsafe features have to be optional. But there are different levels of unsafety, for example one might want to forbid titles in blog comments, to prevent untrusted users from messing with the page layout. Or one might want to forbid all links for more-untrusted users while allowing them for not-so-untrusted users. So it seemed better to engineer the parser around making it possible to allow or forbid any combination of features. So the online-parser loop variant means that any active character must have its semantics decided immediately, and the loose coupling means other language elements cannot interfere in the semantics decision. Other hand, CommonMark seems to have certain ideas about parser architecture leaking into the specification. For example the notion of precedence is directly at odds with the description of the previous paragraph. Consider for example the following ambiguous Markdown code, which is example 239 of current CommonMark specification: *foo`*` When the leading star is encountered, my parser has to scan for the closing star, and doing so without considering the backtick, since code spans might very well have been disabled. So my parser processes it as an emphasis that happen to contain a backtick. Meanwhile, CommonMark prescribes code spans as having a higher precedence than emphasis, so the example should be parsed as a code span that happens to contain a star. As you can imagine, this isn't an isolated example, otherwise working around it or cheating would have been easy. Most the span-level examples / specifications actually involve the more general rule of having leaf span elements taking precedence over container span elements. (Which again is fine by itself, I have nothing against it, it is just poorly compatible with my existing design.) The precedence of fenced code blocks over reference declarations raises a similar problem, although to a smaller extent. I admit I haven't yet looked deeply into the subtleties of block-level language elements, but even if everything went best on that area, the parser would still look ridiculous on the test suite without putting tremendous work. I will do my best to answer to any question or comments, but because of various issues, I might need up to a few days to post answers. Thanks for your attention, Natacha pgpOk6adVqOQb.pgp Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
On Sun, Sep 28, 2014 at 5:36 PM, Natacha Porté nata...@instinctive.eu wrote: authors hope). Fortunately, there is no rush to take such a decision, as a community we can reasonably to wait and see how CommonMark adoption pans out. [1]: http://commonmark.org/ i am completely ambivalent on the topic of which wiki formats Fossil should/should not support, but will offer a few observations... - i have never seen a project called common-anything which has ever actually become common at all. CommonJS has been trying for years to define common frameworks for JS, with very limited success. In practice, standards arise de facto - from prominent use of the code/practices in real-world projects, and not from an ivory tower decision-making process. - Anyone trying to get a general consensus on wiki formats has probably never observed a true standardization effort in progress. The IEEE standardization effort of JSON has been going on for almost a year and the members are still quibbling about details like numeric precision guarantees. (On the one hand, they want ease of implementation and portability, but on the other hand they want infinite-precision numbers.) CommonJS is another case of this - each of its standards is made up of multiple proposals for similar-yet-different APIs, for which there is _no_ general consensus. - Wiki syntaxes have always been a matter of personal taste, and there are no less than 100 different ones out there in use. To anyone who believes they can convince people to switch to a common dialect... i've got a bridge in Brooklyn i'd like to sell them. i.e. i don't see CommonMark being more than yet another attempt to create a perfect world, and history strongly suggests that they will be fighting an up-hill battle for a while before it ultimately runs out of steams and becomes simply yet another wiki markup platform. i could very well be wrong (as i so _sorely_ was about tablets only 3 or 4 years ago, and 19 years ago with regards to the downfall of Unix), but the term wiki format standardization is almost an oxymoron, and i don't foresee CommonMark breaking that pattern. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
Hello, on Sunday 28 September 2014 at 17:58, Stephan Beal wrote: - Wiki syntaxes have always been a matter of personal taste, and there are no less than 100 different ones out there in use. To anyone who believes they can convince people to switch to a common dialect... i've got a bridge in Brooklyn i'd like to sell them. i.e. i don't see CommonMark being more than yet another attempt to create a perfect world, and history strongly suggests that they will be fighting an up-hill battle for a while before it ultimately runs out of steams and becomes simply yet another wiki markup platform. i could very well be wrong (as i so _sorely_ was about tablets only 3 or 4 years ago, and 19 years ago with regards to the downfall of Unix), but the term wiki format standardization is almost an oxymoron, and i don't foresee CommonMark breaking that pattern. I completely share the opinion above, except I'm afraid you have misunderstood the goal of CommonMark: it's not about unifying or standardizing wiki format, only unifying Markdown. The root problem was not the plethora of wiki formats, or the even larger plethora of lightweight markup languages; it was only the ambiguities in the original Markdown specification. There are almost two dozen independent implementations of something called Markdown, and yet each of them implement a language that is subtly different from all the others. A tower-of-Babel effect. You could argue that yet-another variant of Markdown that is subtly different from all the others would only add to the problem (see http://xkcd.com/927/ ), and you might very well be right. The only hopes it won't do more are than good (with regards to fragmentation and ambiguity of the label Markdown) come from that the only variant that is perfectly well-defined, without any ambiguous construct, with a complete test-suite, and that big-website using Markdown will go for CommonMark (Stack Exchange, GitHub and Reddit). But this is still about disambiguating Markdown, without looking at any other wiki or markup format. Natacha pgpGMoBEco1Ac.pgp Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
On Sun, Sep 28, 2014 at 6:39 PM, Natacha Porté nata...@instinctive.eu wrote: I completely share the opinion above, except I'm afraid you have misunderstood the goal of CommonMark: it's not about unifying or standardizing wiki format, only unifying Markdown. i understand that, but there are several competing dialects already, and no truly overwhelming reason to consolidate them. If the benefits were 100% clear and compelling, it would already have replaced the other dialects. But this is still about disambiguating Markdown, without looking at any other wiki or markup format. If it is incompatible with _any_ existing Markdown dialects, then it is effectively a competing format. If there are over 2 dozen slightly different implementations, what are the real chances of getting those two dozen projects to consolidate on one standard? And then what are the chances that all of them will change their parsers to all work identically (which seems like quite a waste of effort, to have 20+ implementations which all work identically). i still predict utter failure ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
http://xkcd.com/927/ -- D. Richard Hipp Sent from phone - Excuse brevity On Sep 28, 2014 12:46 PM, Stephan Beal sgb...@googlemail.com wrote: On Sun, Sep 28, 2014 at 6:39 PM, Natacha Porté nata...@instinctive.eu wrote: I completely share the opinion above, except I'm afraid you have misunderstood the goal of CommonMark: it's not about unifying or standardizing wiki format, only unifying Markdown. i understand that, but there are several competing dialects already, and no truly overwhelming reason to consolidate them. If the benefits were 100% clear and compelling, it would already have replaced the other dialects. But this is still about disambiguating Markdown, without looking at any other wiki or markup format. If it is incompatible with _any_ existing Markdown dialects, then it is effectively a competing format. If there are over 2 dozen slightly different implementations, what are the real chances of getting those two dozen projects to consolidate on one standard? And then what are the chances that all of them will change their parsers to all work identically (which seems like quite a waste of effort, to have 20+ implementations which all work identically). i still predict utter failure ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
Hello: Thanks Natasha, for reviewing the CommonMark specification and identifying issues applicable to your Fossil - Markdown parser. Your arguments are persuasive. Your obvious skill and knowledge about markdown and general text parsing would be of high value to the CommonMark group and I think any comments you presented to them would be welcomed and might affect their specification itself. Last year I struggled with adding markdown documents to the wiki, intending to use Fossil for non-programmer documentation tasks. Like other Fossil users, I decided to store documents as ordinary versioned files and deprecated the wiki. Another consideration was the need to generate pdf versions with paging control. I now use John MacFarlane's pandoc program with documents in pandoc markdown, storing them in Fossil repositories. http://johnmacfarlane.net/pandoc/README.html#pandocs-markdown John MacFarlane is a principal author of the CommonMark specification. I found a utility, gouda.pl, which asks for a table of contents file for a directory's worth of markdown files and then uses pandoc to generate html and pdf output versions, including the table of contents as a link list. The author withdrew that perl script to favour one written in clojure, requiring the Java virtual machine which I did not want to install. http://www.unexpected-vortices.com/sw/rippledoc/ The author, John Gabrielle, wrote another version in python: https://github.com/npettiaux/gouda I am still using the perl version and this combination meets my present needs. Your Fossil-markdown parser presents a good display for the features that I use and treats as plain text the '\pagebreak' instructions intended for pdf paged output. Markdown is versatile, simple format but the multiplicity of standards limits its universality. I hope you can contribute to the making of such a standard. Thanks again, Trevor On Sun, 28 Sep 2014 15:36:27 + Natacha Porté nata...@instinctive.eu wrote: Hello, as you might already know, I'm the primary author of libsoldout and its integration into fossil to perform markdown-to-html conversion. If you followed recent news, you might have heard of CommonMark[1], which is an attempt to unify most implementations and extensions of Markdown, by providing a non-ambiguous specification. It's an honorable goal, so it makes sense to try to converge existing implementations towards the new standard. Unfortunately, the architecture of the parser makes it extremely difficult to implement CommonMark, probably even more difficult than writing a new parser from scratch. In the rest of the e-mail I will detail why I think so, in case some of the brilliant minds find a mistake in my reasoning and a way to implement CommonMark easily in fossil. In case I'm not wrong, it raises the question of changing the markdown engine integrated in fossil, or purposefully forsake CommonMark support (which might make sense if its adoption ends up not as wide as its authors hope). Fortunately, there is no rush to take such a decision, as a community we can reasonably to wait and see how CommonMark adoption pans out. [1]: http://commonmark.org/ The heart of the architecture is built around an online parser: the input is considered as an infinite stream of characters, and each component of the parser either consumes input characters or hand over control to another component, with control transfer made in such a way that there is no loop without input character consumption. The main advantage of such an architecture is how easy it is to prove that in actually terminates, and to prove upper bounds on memory usage. When components are loosely coupled, which is the case here, it also makes debugging much easier. The main drawback is that there is no backtracking possible without cheating, and very limited look-ahead without severely tightening the coupling between components. Moreover, when designing the parser, I enforced very loose coupling between component by requiring all language elements to be individually added or removed from the parser. The reason for that is that complete Markdown is extremely powerful, especially because of raw HTML input features. That's too powerful for untrusted input, like blog comments or wikipages. So unsafe features have to be optional. But there are different levels of unsafety, for example one might want to forbid titles in blog comments, to prevent untrusted users from messing with the page layout. Or one might want to forbid all links for more-untrusted users while allowing them for not-so-untrusted users. So it seemed better to engineer the parser around making it possible to allow or forbid any combination of features. So the online-parser loop variant means that any active character must have its semantics decided immediately, and the loose coupling means other language elements cannot interfere in the semantics decision.
Re: [fossil-users] Pessimism about CommonMark in fossil
Stephan Beal decía, en el mensaje Re: [fossil-users] Pessimism about CommonMark in fossil del domingo, 28 de septiembre de 2014 13:45:58: On Sun, Sep 28, 2014 at 6:39 PM, Natacha Porté nata...@instinctive.eu mailto:nata...@instinctive.eu wrote: But this is still about disambiguating Markdown, without looking at any other wiki or markup format. If it is incompatible with _any_ existing Markdown dialects, then it is effectively a competing format. If there are over 2 dozen slightly different implementations, what are the real chances of getting those two dozen projects to consolidate on one standard? And then what are the chances that all of them will change their parsers to all work identically (which seems like quite a waste of effort, to have 20+ implementations which all work identically). i still predict utter failure ;). My 0.02 Credits: didn't the name CommonMark (and not *Markdown) had to be created because the creator of Markdown himself disowned the effort and DEMANDED that the name Markdown wasn't used? More reason to agree with Stephan's prediction. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
