Re: [fossil-users] The case for Markdown (yes, I rtfm)
On Wed, 5 May 2010 14:48:33 +0200, Gour g...@gour-nitai.com wrote: On Wed, 05 May 2010 13:09:34 +0200 renework == renew...@xs4all.nl wrote: renework I'm not clear for what you are going to use this for. I'll try to explain... renework If for writing documentation, say a user manual. Then You renework don't want to use fossil markup. I'd like to use it for user manual. You get into trouble if it is contained in two wiki pages. Basically your are better of to write two markdown files and a Makefile. Which you can do in Darcs anyway. renework (I use markup in a general sense not a specific product) No problem. Product is 'markdown'. ;) renework You might want to use fossil as a scm for storing your renework documentation files. That is possible. renework (Not if you're using native word format :-) Fortunately, I'm not. After having bad experience with Lotus Word Pro many years ago (while using OS/2) I've decided not to use binary format for my writing ever again. renework If you would use say asciidoc renework http://www.methods.co.nz/asciidoc/ as fossil markup. renework Then generating A wikiPAGE could take A long time. Asciidoc renework is overkill for that purpose. I don't like Asciidoc and Docbook toolchain. Otoh, Markdown is quite readable markup, mature, with many implementations etc. I looked up markdown and it is a 35Kb perl source file. But you are in luck there is a c implementation http://www.pell.portland.or.us/~orc/Code/discount/ Now find someone to incorporate it into fossil. renework If you would enhance wiki pages for wiki purposes then a renework markup containing more functions is called for. Yes, I'd also like enhanced capabilities for wiki pages and I see that it's even on Fossil's TODO list: Ability to attach image files (GIFs and JPEGs) and refer to these in wiki pages. Enhance wiki to the point where it can host the existing fossil documentation. (http://www.fossil-scm.org/index.html/wiki?name=To+Do+List) renework Richard wants to keep his past documentation efforts. I fully understand that, but if he would decide to support Markdown, I'd be ready to convert all the Fossil docs from the present wiki to it. renework Assuming that the creole functionality satisfies your needs. No interest for creole since I'm involved with Haskell and there is very nice Pandoc allowing me to use Markdown as single-source markup capable to convert to plethora of end formats (HTML, PDF...) renework However nice it is to ramble along, The question is still renework what do you want to do with the markup? To use (more) 'standard' wiki markup like Markdown which has support in different tools (e.g. Pandoc for processing it, different blog-engines support writing in it, there is Emacs-mode for it etc.) for all my documentation-related needs instead of learning new wiki for every app I need. You do understand that other users have there own preferences for markup implementations and they all claim that theirs is the best and most standard? The present Fossil's markup lacks features in order to be used as single-source markup which is pity and forces one to use another markup for writing other docs. Richard likes HTML markup :-) . But pandoc can convert HTML to markdown (Aha do I see a way out of typing a lot of documents :-) (Before settling on markdown, I was thinking about reST and same reasoning applies there as well.) The solution I presented for creole could just as easy be used for markdown e.g. ** bold markdown this is markdown fossil and back in fossil That would spare you a lot of typing :-) also But it might bring you into trouble with pandoc because pandoc might not understand markdown my advice would be to use DARCS, write your user manual and keep the files in DARCS and use pandoc to your harts content. There is much work involved with what you want and it won't happen overnight if ever. Sincerely, Gour ___ 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] The case for Markdown (yes, I rtfm)
On 05/05/2010 10:53 AM, Twylite wrote: That said, if you really want Markdown, why don't you use something like Attacklab's Showdown (http://attacklab.net/showdown/), which is a Markdown implementation in JavaScript. Write your Wiki pages in plain text, include Showdown in the site header, and with a little fiddling you should be able to have the Markdown rendered into HTML on the browser. That's the plan, though my intention is to render the markdown to HTML at post time and store both the markdown and HTML text. -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ 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] The case for Markdown (yes, I rtfm)
On Wed, 05 May 2010 16:53:27 +0200 Twylite == Twylite wrote: Twylite Plugins are of limited value. The repository becomes Twylite non-portable except to other Fossil installations with the Twylite same plugins. The end of that road is that everyone has to Twylite have all the markup plugins, and a significant part of the Twylite value of Fossil is lost. Yeah, you're right. Let's forget plugin idea. Twylite The only thing Markdown offers is a claim of being easier for Twylite authors to work with than HTML. I say a claim because there Twylite are plenty of people who disagree, in particular those who are Twylite blessed by having to work with five different markup languages Twylite in a day. Hmm, maybe I'm spoiled by Pandoc's extensions...check http://johnmacfarlane.net/pandoc/README.html#pandocs-markdown-vs.standard-markdown) Twylite Markdown does NOT have automation features that are common to Twylite most Wikis, and essential for creating complex documents (e.g. Twylite Table of Contents, notices callouts, numbered headings). Heh, Pandoc has -N or --number-sections option which causes sections to be numbered in LaTeX, ConTeXt, or HTML output. By default, sections are not numbered. :-) Twylite That said, if you really want Markdown, why don't you use Twylite something like Attacklab's Showdown Twylite (http://attacklab.net/showdown/), which is a Markdown Twylite implementation in JavaScript. Write your Wiki pages in plain Twylite text, include Showdown in the site header, and with a little Twylite fiddling you should be able to have the Markdown rendered into Twylite HTML on the browser. This sounds like something which Joshua wants to do. Thanks for the input. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 signature.asc 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] The case for Markdown (yes, I rtfm)
On Wed, 05 May 2010 16:32:29 +0200 renework == renework wrote: renework You get into trouble if it is contained in two wiki pages. renework Basically your are better of to write two markdown files and renework a Makefile. Which you can do in Darcs anyway. Well, the more I think about it, it seems that it's better to forget about fossil's wiki as solution for documentation and use it only according to the DRH's intention. :-) renework I looked up markdown and it is a 35Kb perl source file. But renework you are in luck there is a c implementation renework http://www.pell.portland.or.us/~orc/Code/discount/ renework Now find someone to incorporate it into fossil. Still, it won't be accepted in the core, so better to forget about it. renework You do understand that other users have there own preferences renework for markup implementations and they all claim that theirs is renework the best and most standard? Sure. I understand, but I posted since this thread is labelled as: The case for Markdown. ;) renework my advice would be to use DARCS, write your user manual and renework keep the files in DARCS and use pandoc to your harts renework content. There is much work involved with what you want and renework it won't happen overnight if ever. I understand your suggestion to write user-manual with markdown and use pandoc, but why are you suggesting to use darcs instead of fossil as scm? Maybe there are too many users already? :-D Well, it is a topic for a new post... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 signature.asc 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] The case for Markdown (yes, I rtfm)
On Tue, 04 May 2010 10:39:22 -0400 Joshua == Joshua Painewrote: Joshua If it's safe for your use case to turn on 'allow all html Joshua tags' (it's not safe if you let the general public create or Joshua edit tickets or wiki pages), then it's possible to implement Joshua Markdown for fossil wiki all on the client side (i.e., a script Joshua included in the header). Well, considering that for now I'd allow only team-members to create tickets, it would be safe. Still, I wonder, what would happen in regards to spam if we would allow creating tickets by the public... Joshua I've implemented (and subsequently Joshua misplaced) a proof of concept and worked it all out in my head, Joshua including the awkward bits about the different kinds of system Joshua links, but so far I haven't made time to properly implement it Joshua (and the next 3 weeks, at least, are almost certainly out of Joshua the question). It is not such a rush. I'm still investigating about the toolchain. Joshua DRH did not comment on the original thread, which I took to Joshua mean no as far as implementing markdown in core. My plan is Joshua to get the client-side version all working, convenient, and Joshua beautiful, and hope for an outpouring of support/requests to Joshua have it in core. ;-) Sure, if there is any chance to bring it in the core, I'll fill some support ticket(s). :-) Otherwise, we'll stay with darcs and maybe deploy Gitit (http://gitit.johnmacfarlane.net/) - wiki written in Haskell which uses darcs Pandoc, i.e. one can use it with Markdown. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 signature.asc 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] The case for Markdown (yes, I rtfm)
There is exists no wiki markup that will make everybody happy. Any choice of wiki markup will leave some users grumbling that a different choice should have been made. I am personally very happy with the current wiki markup in Fossil. It meets my needs very well. And even if someone where able to come up with a markup that met my needs better, at this point I have written so much using the current markup that I have little interest in changing. So, please do not expect me to spend time working on another wiki markup. On the other hand, if you want to hack up Fossil to support Markdown or whatever other wiki markup suites you, then by all means have at it. You will not hurt my feelings in the least. Note that Fossil is self-hosting, so you can very easily clone the entire source history then add Markdown support in your private repository. With an inexpensive shared-hosting account, you can publish your Fossil-clone so that others who prefer Markdown can use your version of Fossil rather than the canonical version. And you can do period pulls against the canonical Fossil repository and merge changes from it into your branch. And you can do all of this with my blessings. Just please don't ask me to do the hacking for you, nor support your changes after the fact. On Tue, May 4, 2010 at 9:54 AM, Gour g...@gour-nitai.com wrote: On Sun, 29 Nov 2009 12:07:06 -0500 Joshua == jos...@letterblock.com wrote: Hello list, I know I may be beating the dead horse, but... Joshua I recognize that the improvement I and others are asking for Joshua may be non-trivial to implement, so while I think markdown (the Joshua particular format, not the general class of) is an obvious Joshua choice because it allows those who prefer plain HTML to just Joshua keep writing HTML without change, if something else is easier Joshua to integrate or otherwise preferable I'll happily embrace it. Here is avid darcs user familiar enough with several DVCS (bzr, hg, git), but except fossil there is none appealing enough to replace darcs. Having some 'standard' wiki markup is one of the things I researched as soon as I visited fossil site today (after having short enocunter in Sept '09). For a long time I was thinking to use reST/Sphinx for my projects' docs, but gaving up on some Python technology (Django) and decided to use Haskell, I've returned back to Markdown considering there is excellent implementation in Pandoc (http://johnmacfarlane.net/pandoc/) which supports some nice extensions as well. The usage of Markdown/Pandoc for end-user docs is quite appropriate considering that one can convert Markdown markup into HTML/LaTeX/ConTeXt etc. which would make Markdown excellent choice for wiki format in Fossil. I saw (at the end of the thread), there fossil-creole markup, but just wonder if there is still some live in the dead-horse of Markdown-as-fossil-wiki-format? Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- - D. Richard Hipp d...@sqlite.org ___ 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] The case for Markdown (yes, I rtfm)
On Tue, 4 May 2010 11:28:03 -0400 Richard == Richard Hipp wrote: Richard There is exists no wiki markup that will make everybody Richard happy. Any choice of wiki markup will leave some users Richard grumbling that a different choice should have been made. I'm very well aware of it...and not knowledgable enough to know if some kind of plugin system supporting different markup would work. Richard I am personally very happy with the current wiki markup in Richard Fossil. It meets my needs very well. And even if someone Richard where able to come up with a markup that met my needs better, Richard at this point I have written so much using the current markup Richard that I have little interest in changing. So, please do not Richard expect me to spend time working on another wiki markup. I understand your rationale for the current wiki markup and respect it, as well as being thankful for providing fossil at the first place. However, the whole idea of more 'standard' and/or capable wiki is due to desire to extend its usage for all documentation needs one may have while working on the project...and I believe you agree that writing HMTL is not solution for writing e.g. manuals which require more structured markup than the present wiki is capable of. Richard On the other hand, if you want to hack up Fossil to support Richard Markdown or whatever other wiki markup suites you, then by all Richard means have at it. You will not hurt my feelings in the Richard least. Note that Fossil is self-hosting, so you can very Richard easily clone the entire source history then add Markdown Richard support in your private repository. With an inexpensive Richard shared-hosting account, you can publish your Fossil-clone so Richard that others who prefer Markdown can use your version of Fossil Richard rather than the canonical version. And you can do period pulls Richard against the canonical Fossil repository and merge changes from Richard it into your branch. And you can do all of this with my Richard blessings. Thank you for the blessings...too bad I'm not C-coder and even though I would be, I believe that making 'Markdown-fork' with the need for constant merge is not solution either. Richard Just please don't ask me to do the hacking for you, nor Richard support your changes after the fact. My question was not request that you do the hacking, but more a quest for something which Joshua is thinking about... Pls. excuse me if my post gave the wrong impression. Now it's clear... Does it also mean you are still the only coder involved in fossil? At the end it seems that it is possible to choose between the option to live with the present limited wiki markup or use other solution(s)... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 signature.asc 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] The case for Markdown (yes, I rtfm)
This is kind of funny. We have been debating this and the end result was something to the effect of: Yeah, it may be good, but who will program it? It's already done and has been by Robert... http://fossil-scm.org/index.html/timeline?t=creole So, no dependencies, the code is written and Creole is a format that many wiki systems are now supporting. Jeremy ___ 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] The case for Markdown (yes, I rtfm)
Try closer to 40. It may be a small number compared to the amount of people who download Fossil but I believe it to be a representative number. So yes, I'm calling this an overwhelming majority. You can stick your head in the sand if you want but this is a pretty clear cut case of: Software is lacking, there is room for improvement, a majority desire improvement. This kind of stagnation over something that is clearly a needed improvement is likely to make me walk away from Fossil. On Sat, Dec 5, 2009 at 1:14 PM, Michael McDaniel fos...@autosys.us wrote: On Sat, Dec 05, 2009 at 03:26:20PM -0500, Joshua Paine wrote: On Sat, 2009-12-05 at 11:46 -0800, Kurtis Rainbolt-Greene wrote: If the feature were put in wouldn't it just be people with old fossil needing to update? Yes, but... I'm not sure I get why there's talk of custom fossil. This is a feature that a overwhelming majority want. ^ Let us please keep a context when using loaded phrases such as overwhelming majority want. I believe the context for the phrase is a straw poll which was taken by approximately twenty people who subscribe to this mailing list. Likely there are more people than myself who subscribe and did not vote. My unsupported-by-evidence belief is that there are magnitudes more people who use fossil than the twenty or so votes in the straw poll. I doubt that we can accurately extrapolate all users' sentiments from that poll. A download counter at fossil-scm.org may provide a sense of how much fossil is used (of course, each download does not necessarily indicate a new user or users). The current fossil wiki and embedded documentation are fine by me. If people want to add to their own stuff, they have that capability. I most especially would want never to see, e.g. javascript as a mandatory part of using fossil. Many scripting languages, and javascript particularly, are great holes for inserting code to compromise a machine via the web browser. I prefer my source control management system to present as few risks as possible for code corruption, undesired distribution, or compromise of my users' machines when using the SCM. No doubt I am not alone with that sentiment. ~Michael But it's a feature that DRH said some time ago on the fossil site that he considered and rejected, and since he has stayed out of this conversation, I conclude that he's sticking to his decision or at best will reconsider only if some working code appears. If one were to implement markdown or some other more complete text formatting language in C, DRH might still not be willing to include it, so that route means hoping DRH will change his mind, or settling for a custom version of fossil. -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Michael McDaniel Portland, Oregon, USA http://trip.autosys.us ___ 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] The case for Markdown (yes, I rtfm)
On Sun, December 6, 2009 at 9:57 am, Kurtis Rainbolt-Greene thinkwritem...@gmail.com wrote: Try closer to 40. It may be a small number compared to the amount of people who download Fossil but I believe it to be a representative number. So yes, I'm calling this an overwhelming majority. You can stick your head in the sand if you want but this is a pretty clear cut case of: Software is lacking, there is room for improvement, a majority desire improvement. This kind of stagnation over something that is clearly a needed improvement is likely to make me walk away from Fossil. In spite of your remarks, I don't think there is a clear consensus that some particular markup should be implemented. Your remarks don't actually contribute to obtaining such a consensus. A change will only happen when someone thinks it is important enough to spend their time implementing it. As far as the wiki markup is concerned, we are still waiting. Eric ___ 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] The case for Markdown (yes, I rtfm)
Will Duquette wrote: On Dec 5, 2009, at 3:23 AM, Daniel Clark wrote: Joshua Paine wrote: On Fri, 2009-12-04 at 16:21 -0500, Daniel Clark wrote: I'm missing why you wouldn't want to just implement this as code (in C or Javascript) that can translate from fossil wiki markup to markdown markup (or whatever) and back. Doing it in C, if it's not integrated into fossil core, means to use my repo correctly, you need my custom version of fossil. Bleh. The entire point is that if done in this manner people wouldn't *need* custom versions of fossil (or non-fossil plugins) - custom versions of fossil (or non-fossil plugins) would just add the ability to edit text in a user's preferred format (and then convert and save that as fossil wiki format). Fossil itself would only ever see/store fossil wiki markup, so users without the custom versions of fossil (or non-fossil plugins) could continue to edit text in fossil wiki format. Users of mainline fossil would not need to know or care that custom versions of fossil (or non-fossil plugins) existed. Then you'd need round-trip capability from (say) Markdown to Fossil+HTML and back again. And then, someone without the plug-in would edit some wiki pages, editing the HTML produced from some Markdown construct not directly translatable into Fossil's markup and hence represented in HTML, and editing that HTML in such a way that it couldn't be translated back into Markdown syntax again. It would then remain HTML, and everyone would be unhappy. I fail to see how this is much different from the way the wiki deals with normal errors (eg saves them, user needs to edit the text if it's not what was intended). Also it seems that the majority of such errors could be treated as bugs and then fixed in the code / in the next fossil rebuild operation (in the case of this feature being added as code to fossil). -- Daniel JB Clark | Sys Admin, Free Software Foundation pobox.com/~dclark | http://www.fsf.org/about/staff#danny ___ 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] The case for Markdown (yes, I rtfm)
Hi, Try closer to 40. It may be a small number compared to the amount of people who download Fossil but I believe it to be a representative number. Your lack of understanding of negative response bias doesn't make it go away. The majority have been silent on this issue, which doesn't tell us anything either way. This kind of stagnation over something that is clearly a needed improvement is likely to make me walk away from Fossil. Fossil is Open Source. If you feel that such a feature is needed, then implement it. If you are unable to then pay someone to implement it for you. And once you have implemented it the custodians of the project may accept your contribution; or they may not, in which case you can maintain your own fork. Stagnation is just maturity by another name. Twylite ___ 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] The case for Markdown (yes, I rtfm)
Joshua Paine wrote: On Fri, 2009-12-04 at 16:21 -0500, Daniel Clark wrote: I'm missing why you wouldn't want to just implement this as code (in C or Javascript) that can translate from fossil wiki markup to markdown markup (or whatever) and back. Doing it in C, if it's not integrated into fossil core, means to use my repo correctly, you need my custom version of fossil. Bleh. The entire point is that if done in this manner people wouldn't *need* custom versions of fossil (or non-fossil plugins) - custom versions of fossil (or non-fossil plugins) would just add the ability to edit text in a user's preferred format (and then convert and save that as fossil wiki format). Fossil itself would only ever see/store fossil wiki markup, so users without the custom versions of fossil (or non-fossil plugins) could continue to edit text in fossil wiki format. Users of mainline fossil would not need to know or care that custom versions of fossil (or non-fossil plugins) existed. -- Daniel JB Clark | Sys Admin, Free Software Foundation pobox.com/~dclark | http://www.fsf.org/about/staff#danny ___ 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] The case for Markdown (yes, I rtfm)
I'm not sure I get why there's talk of custom fossil. This is a feature that a overwhelming majority want. If the feature were put in wouldn't it just be people with old fossil needing to update? On Sat, Dec 5, 2009 at 8:29 AM, Will Duquette w...@wjduquette.com wrote: On Dec 5, 2009, at 3:23 AM, Daniel Clark wrote: Joshua Paine wrote: On Fri, 2009-12-04 at 16:21 -0500, Daniel Clark wrote: I'm missing why you wouldn't want to just implement this as code (in C or Javascript) that can translate from fossil wiki markup to markdown markup (or whatever) and back. Doing it in C, if it's not integrated into fossil core, means to use my repo correctly, you need my custom version of fossil. Bleh. The entire point is that if done in this manner people wouldn't *need* custom versions of fossil (or non-fossil plugins) - custom versions of fossil (or non-fossil plugins) would just add the ability to edit text in a user's preferred format (and then convert and save that as fossil wiki format). Fossil itself would only ever see/store fossil wiki markup, so users without the custom versions of fossil (or non-fossil plugins) could continue to edit text in fossil wiki format. Users of mainline fossil would not need to know or care that custom versions of fossil (or non-fossil plugins) existed. Then you'd need round-trip capability from (say) Markdown to Fossil+HTML and back again. And then, someone without the plug-in would edit some wiki pages, editing the HTML produced from some Markdown construct not directly translatable into Fossil's markup and hence represented in HTML, and editing that HTML in such a way that it couldn't be translated back into Markdown syntax again. It would then remain HTML, and everyone would be unhappy. -- Daniel JB Clark | Sys Admin, Free Software Foundation pobox.com/~dclark http://pobox.com/%7Edclark | http://www.fsf.org/about/staff#danny ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] The case for Markdown (yes, I rtfm)
On Sat, 2009-12-05 at 11:46 -0800, Kurtis Rainbolt-Greene wrote: If the feature were put in wouldn't it just be people with old fossil needing to update? Yes, but... I'm not sure I get why there's talk of custom fossil. This is a feature that a overwhelming majority want. But it's a feature that DRH said some time ago on the fossil site that he considered and rejected, and since he has stayed out of this conversation, I conclude that he's sticking to his decision or at best will reconsider only if some working code appears. If one were to implement markdown or some other more complete text formatting language in C, DRH might still not be willing to include it, so that route means hoping DRH will change his mind, or settling for a custom version of fossil. -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ 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] The case for Markdown (yes, I rtfm)
On Sat, Dec 05, 2009 at 03:26:20PM -0500, Joshua Paine wrote: On Sat, 2009-12-05 at 11:46 -0800, Kurtis Rainbolt-Greene wrote: If the feature were put in wouldn't it just be people with old fossil needing to update? Yes, but... I'm not sure I get why there's talk of custom fossil. This is a feature that a overwhelming majority want. ^ Let us please keep a context when using loaded phrases such as overwhelming majority want. I believe the context for the phrase is a straw poll which was taken by approximately twenty people who subscribe to this mailing list. Likely there are more people than myself who subscribe and did not vote. My unsupported-by-evidence belief is that there are magnitudes more people who use fossil than the twenty or so votes in the straw poll. I doubt that we can accurately extrapolate all users' sentiments from that poll. A download counter at fossil-scm.org may provide a sense of how much fossil is used (of course, each download does not necessarily indicate a new user or users). The current fossil wiki and embedded documentation are fine by me. If people want to add to their own stuff, they have that capability. I most especially would want never to see, e.g. javascript as a mandatory part of using fossil. Many scripting languages, and javascript particularly, are great holes for inserting code to compromise a machine via the web browser. I prefer my source control management system to present as few risks as possible for code corruption, undesired distribution, or compromise of my users' machines when using the SCM. No doubt I am not alone with that sentiment. ~Michael But it's a feature that DRH said some time ago on the fossil site that he considered and rejected, and since he has stayed out of this conversation, I conclude that he's sticking to his decision or at best will reconsider only if some working code appears. If one were to implement markdown or some other more complete text formatting language in C, DRH might still not be willing to include it, so that route means hoping DRH will change his mind, or settling for a custom version of fossil. -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Michael McDaniel Portland, Oregon, USA http://trip.autosys.us ___ 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] The case for Markdown (yes, I rtfm)
Hello Daniel, I'm missing why you wouldn't want to just implement this as code (in C or Javascript) that can translate from fossil wiki markup to markdown markup (or whatever) and back. I think everyone here is interested in any markup implementation. However, there's only one implementation of Markdown in C (discount), and no implementations of Textile, or most other languages. Why? Because it's hard. I guess everyone would be interested in any markup implementation (and creole is already in the branch), but the question is -- who'll do it. It's not that everyone doesn't want other markups. I personally would be interested if someone would write Markdown/Textile/whatever in C, but... who? Maybe instead of flaming here someone could actually write the code? -- Dmitry Chestnykh Coding Robots dmi...@codingrobots.com http://www.codingrobots.com ___ 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] The case for Markdown (yes, I rtfm)
On Fri, 2009-12-04 at 16:21 -0500, Daniel Clark wrote: I'm missing why you wouldn't want to just implement this as code (in C or Javascript) that can translate from fossil wiki markup to markdown markup (or whatever) and back. Doing it in C, if it's not integrated into fossil core, means to use my repo correctly, you need my custom version of fossil. Bleh. For wiki and bug reports, this could in principle be done with JavaScript. But it's not optimal, b/c the fossil wiki syntax is just plain weak, and as solutions to there are too many options for X go, I'll make yet another that is less functional than any of them! is one of the worst, IMO. So any code to translate to/from fossil wiki will not be useful elsewhere, hence less likely to get written. And for .wiki files in the source tree, only the built-in formatting is possible. But there is a fair amount of Programming is hard--let's go shopping [for someone to solve my problem for me!] here, not least on my part. In defense of me, my original request was simply to acknowledge the problem and be open to fixes if DRH (or anyone else who contributes and/or has any experience writing C--I really don't know how this project is structured) doesn't have interest and/or time to fix it. I have little C-fu, DRH doesn't seem interested anyway, so my plan henceforth is to shut up about it until I have a working JavaScript solution or can contribute to someone else's effort. (And I'll add one more time that while I think this aspect of fossil is wrong and even wrong-headed, I otherwise love fossil, love SQLite, and admire DRH.) -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ 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] The case for Markdown (yes, I rtfm)
I'm not going to bother stopping it, nor did I plan to. I was only showing you what the first 10m showed. Now? YES: 13 NO: 3 Any: 13 Markdown: 3 Creole: 1 Don't forget to add in the Apathetic or Not sures. I'm so unsure and apathetic, I don't remember which one I picked. I do know I firmly ticked Any should it be changed (I take this to include extensions to the current system, if that seems more appropriate). Cheers, B ___ 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] The case for Markdown (yes, I rtfm)
What about just having a few small plugins based on the markdown you want? Separate from the source, not required, 1 plugin per formatting. I don't care what's used, as long as it's not plain HTML. HTML is mental-process retardant. ___ 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] The case for Markdown (yes, I rtfm)
On Sun, Nov 29, 2009 at 5:34 AM, Joshua Paine jos...@letterblock.comwrote: There are only a small handful of popular wiki languages. Some implementations may have more or less features +1 for google code wiki. :) Fossil itself is an example of looking at an already-crowded field and deciding to start over a bit differently anyway, and I'm glad of it: I ...Unlike fossil as a whole vs other SCMs, the wiki formatting provides no advantages at all vs markdown, at least from a user perspective. ...from fossil. For composing text, though, I'm already used to the power and flexibility of markdown, and fossil wiki doesn't meet 90% of my needs--anymore than I'd still be content with SVN. FWIW, i agree wholeheartedly. i've come to a trivial wiki syntax (e.g. google code wiki) to be a real help in documenting my code (of which i do lots). i would love to see fossil adopt one of the more popular standards (though i'm not familiar enough with them to have a strong feeling for one or the other aside from google code wiki). 3. Where the fossil wiki markup language is insufficient, HTML is used. ... HTML does not need to be used very often so is not a burden. The HTML tags are used a lot by those of us who cannot remember the syntax of each wiki format :/. After months of documenting heavily over on google code, i'm finding it hard to use the fossil wiki (different spacing rules for bullets, for example). The formatting rules for fossil wiki are designed to be simple and intuitive. ... with a safe subset of HTML for more complex formatting tasks. i think the current falling back to stripped-down HTML was philosophically the right thing to do. It facilitates the import of older docs without forcing their 'style' and inline scripts and everything onto you. Until this evening I hadn't deeply investigated the other wiki formats. I was surprised to discover that it's not trivial to just use HTML in any of them! That being the case, perhaps you weren't aware that using HTML *is* trivial with markdown? You can freely mix plain HTML in with the markdown formatting without any special escaping. :) I see two ties and one win for markdown. Consider also that with .. DRH--needing a convenient, HTML-compatible wiki format--should just use Markdown: the one very popular already-existing format that supports painless inline HTML. If we're counting votes, here's one for all of Joshua's arguments. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] The case for Markdown (yes, I rtfm)
The number of mails about this just proves that there is no right choice for a new wiki markup. There are plenty of lightweight markup formats out there (with their own enthusiastic followers) that haven't even been mentioned here yet. If you want to do your project documentation a particular way, then do it that way - as project files. The other problem is introducing external dependencies for Fossil - have you noticed how few there are? My vote (somebody else mentioned votes!) is to leave the Fossil wiki alone (except for gradual improvement). Eric ___ 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] The case for Markdown (yes, I rtfm)
Others... I've mentioned other standards, yes. However, I would accept *any* complete format. Creole is NOT better than Markdown and Markdown is NOT better than Textitle and Textile is NOT better than Creole... They all do the same thing. They are all complete. What I am suggesting for the wiki markup is an EXISTING, COMPLETE format, that's all. Further, C libraries exist that could be called as simple as char *html = MarkdownToHTML(char *text)... It could easily be an optional library that those who want real formatting can use, otherwise you can type in verbose HTML. Jeremy From: Michael Richter Sent: Sunday, November 29, 2009 12:53 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) Now to refute this. Keep in mind that if I had my 'druthers I'd have Markdown as well while you read this. Markdown is a non-trivial format to parse and implement. The resulting code is non-trivial in size as well. Not everybody universally accepts Markdown as the format they want. Others want, say, Textile. Or Creole. Or Wikimedia. Or Wikidot. Or ... That is the problem. There's too many choices out there and the choices are not even vaguely compatible with each other. Is Fossil's wiki syntax weak? Yes. Does this mean we should replace it with some other format? Quite possibly. But until there is a clear winner in the format wars with libraries that can be easily integrated (both technically and legally) it probably isn't going to happen, and as much as it pains me--as a Markdown fan--to say this, I agree with Richard's decision reasoning. The alternatives are: a.. Go through all this whining all over again whenever a new format is selected. (But why did you pick MRKdwn?! Creole is SOOO much better because) b.. Go through some incredible code bloat as every format under the sun is hacked in. c.. Lose one of the key attractions to Fossil as repositories get subtly incompatible with each other as this one over here has this obscure markup language hacked in for markup on MacOS that doesn't work on Linux or Windows or ... Personally I don't view the Wiki part of Fossil so important as to put up with all of that constantly. I far prefer the rock-solid database core, the single-executable/single-file-repositories nature, the integrated web services, the built-in ticket management, etc. When I want to do detailed docs with fancy formatting I put it in the documentation tree of the actual source code, not the Wiki. The Wiki seems more suited to quick notes and the like anyway. Could the wiki be more by switching formats? Almost certainly. But the costs are likely too high. 2009/11/29 Joshua Paine jos...@letterblock.com On Sat, 2009-11-28 at 09:10 -0500, D. Richard Hipp wrote: http://www.fossil-scm.org/fossil/wiki_rules I re-read this and noticed again the rationale for using the simple wiki rules included instead of an existing wiki language. Given the rationale, I think Markdown would be a better choice. 1. There is no standard wiki markup language. Every wiki engine does it a little differently. There are only a small handful of popular wiki languages. Some implementations may have more or less features (e.g., Markdown implementations in various languages), but in the case of Markdown at least there is a common core with a test suite which nearly all implementations pass. Fossil itself is an example of looking at an already-crowded field and deciding to start over a bit differently anyway, and I'm glad of it: I find fossil easy to understand, and publishing repositories together with documentation and issue tracking is shockingly easy. But surely having many existing options is not in itself a reason to start over? Unlike fossil as a whole vs other SCMs, the wiki formatting provides no advantages at all vs markdown, at least from a user perspective. 2. The wiki markup used by fossil, though limited, is common to most other wiki engines, is intuitive, and is sufficient for 90% of all formatting tasks. SVN was sufficient for 90%+ of my SCM tasks until I learned about the power of easy branching and merging and distributed development from git and the power of built-in collaboration tools and trivial publishing from fossil. For composing text, though, I'm already used to the power and flexibility of markdown, and fossil wiki doesn't meet 90% of my needs--anymore than I'd still be content with SVN. 3. Where the fossil wiki markup language is insufficient, HTML is used. ... HTML does not need to be used very often so is not a burden. The formatting rules for fossil wiki are designed to be simple and intuitive. ... with a safe subset of HTML for more complex formatting tasks. This is what it really comes down to, isn't it? The formatting should be simple and familiar, and it should
Re: [fossil-users] The case for Markdown (yes, I rtfm)
For those that would like a real human formatting language it would be worth a dependency. For those that prefer to use HTML can simply not link in the library. #ifdef MARKDOWN #include markdown.h #endif ... #ifdef MARKDOWN output = ConvertMarkdown(rawText); #endif ... $ gcc -DMARKDOWN fossil.c -o fossil Pretty easy, eh? Now, that's an over simplification but not by much. Jeremy -- From: Eric e...@deptj.eu Sent: Sunday, November 29, 2009 6:44 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) The number of mails about this just proves that there is no right choice for a new wiki markup. There are plenty of lightweight markup formats out there (with their own enthusiastic followers) that haven't even been mentioned here yet. If you want to do your project documentation a particular way, then do it that way - as project files. The other problem is introducing external dependencies for Fossil - have you noticed how few there are? My vote (somebody else mentioned votes!) is to leave the Fossil wiki alone (except for gradual improvement). Eric ___ 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] The case for Markdown (yes, I rtfm)
And with this you lose the interoperability of Fossil repositories. Go team. 2009/11/29 Jeremy Cowgar jer...@cowgar.com For those that would like a real human formatting language it would be worth a dependency. For those that prefer to use HTML can simply not link in the library. #ifdef MARKDOWN #include markdown.h #endif ... #ifdef MARKDOWN output = ConvertMarkdown(rawText); #endif ... $ gcc -DMARKDOWN fossil.c -o fossil Pretty easy, eh? Now, that's an over simplification but not by much. Jeremy -- From: Eric e...@deptj.eu Sent: Sunday, November 29, 2009 6:44 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) The number of mails about this just proves that there is no right choice for a new wiki markup. There are plenty of lightweight markup formats out there (with their own enthusiastic followers) that haven't even been mentioned here yet. If you want to do your project documentation a particular way, then do it that way - as project files. The other problem is introducing external dependencies for Fossil - have you noticed how few there are? My vote (somebody else mentioned votes!) is to leave the Fossil wiki alone (except for gradual improvement). Eric ___ 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] The case for Markdown (yes, I rtfm)
I'm new to fossil, but if you need a different markup notation you can check it in, along with the tool you need to process it. Stephen On Sunday, November 29, 2009, Kurtis Rainbolt-Greene thinkwritem...@gmail.com wrote: What about just having a few small plugins based on the markdown you want? Separate from the source, not required, 1 plugin per formatting. I don't care what's used, as long as it's not plain HTML. HTML is mental-process retardant. -- -- Stephen De Gabrielle stephen.degabrie...@acm.org Telephone +44 (0)20 85670911 Mobile+44 (0)79 85189045 http://www.degabrielle.name/stephen ___ 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] The case for Markdown (yes, I rtfm)
2009/11/29 Jeremy Cowgar jer...@cowgar.com It has been mentioned that there will be complaining and arguing to what format to choose and yet there has been none, only those who dislike a format *making assumptions* as to what will happen. In other news, irony is my very favourite thing in the whole world. ___ 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] The case for Markdown (yes, I rtfm)
Zed, To some people the documentation of their project is of vital importance and the ability to do that self contained in Fossil is not a minor or marginal issue. Fossil works fantastic for me, the only problem I see right now is the lack of ability to easy document my project. Fossil see's this as important also as it decided to include a wiki in the first place. I see it as such an important task that when choosing between Trac or Fossil for my major projects, I will continue to use Trac simply because I can document my project easily. Until it is as easy to document it in Fossil as it is Trac, I will continue to be a Trac/Hg user. Once we can document easily in Fossil, I'm all there. and, btw, I'm not a casual Fossil user. I have contributed code to Fossil when it was first starting. I did the server TCP/IP code of Fossil to the Windows environment so that I could use the server features on Windows. So, I am all for Fossil, I just place a large importance on the developers documenting the project as well as developing the project. The idea of this being self contained in 1 tool such as Fossil is fantastic but it's not there yet, thus I started this thread. Jeremy -- From: Zed A. Shaw zeds...@zedshaw.com Sent: Sunday, November 29, 2009 3:18 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) On Sat, Nov 28, 2009 at 11:34:09PM -0500, Joshua Paine wrote: On Sat, 2009-11-28 at 09:10 -0500, D. Richard Hipp wrote: http://www.fossil-scm.org/fossil/wiki_rules I re-read this and noticed again the rationale for using the simple wiki rules included instead of an existing wiki language. Given the rationale, I think Markdown would be a better choice. I'm curious, what are your thoughts on the diff algorithm on fossil? I personally liked the algorithm I did way back in the day that used a non-linear delta from a suffix array of the target side and LCS analysis of the source. Or, if that's too complex, let's get back to bikeshedding the wiki syntax: http://en.wiktionary.org/wiki/bikeshedding -- Zed A. Shaw http://zedshaw.com/ ___ 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] The case for Markdown (yes, I rtfm)
My two cents on all of this: regardless of what wiki syntax is used, the Fossil Wiki is a lousy way to do your software documentation. You write your software. Ultimately, you deliver your software. Then you want to deliver your documentation *with* your software...and it's in a wiki tied to your CM repository, and you've got a problem. The Fossil wiki is a great way to easily create your project's web pages: development news, installation instructions, download pages, FAQs, and the like. It's great for meta-documentation, and for communication among the development team. Use it for more than that and you're asking for trouble. On Nov 29, 2009, at 6:49 AM, Jeremy Cowgar wrote: Not at all as Markdown, Creole or Textile all look great as plain text. Those without the plugin will simply not have glorified HTML markup but they will still be able to participate. However, I only mentioned this option as some think proper wiki formatting is too much work. My real suggestion would be for fossil to adopt 1 major format as the format to use. Those that wish to use verbose HTML can still do so. Those that wish to have a nice formatting language that's easy to maintain/type/read/understand can use the formatting engine. No one looses. I'm failing to see how such an addition is generating such a vocal attack by a few. It has been mentioned that there will be complaining and arguing to what format to choose and yet there has been none, only those who dislike a format making assumptions as to what will happen. Jeremy From: Michael Richter Sent: Sunday, November 29, 2009 9:36 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) And with this you lose the interoperability of Fossil repositories. Go team. 2009/11/29 Jeremy Cowgar jer...@cowgar.com For those that would like a real human formatting language it would be worth a dependency. For those that prefer to use HTML can simply not link in the library. #ifdef MARKDOWN #include markdown.h #endif ... #ifdef MARKDOWN output = ConvertMarkdown(rawText); #endif ... $ gcc -DMARKDOWN fossil.c -o fossil Pretty easy, eh? Now, that's an over simplification but not by much. Jeremy -- From: Eric e...@deptj.eu Sent: Sunday, November 29, 2009 6:44 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) The number of mails about this just proves that there is no right choice for a new wiki markup. There are plenty of lightweight markup formats out there (with their own enthusiastic followers) that haven't even been mentioned here yet. If you want to do your project documentation a particular way, then do it that way - as project files. The other problem is introducing external dependencies for Fossil - have you noticed how few there are? My vote (somebody else mentioned votes!) is to leave the Fossil wiki alone (except for gradual improvement). Eric ___ 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 ___ 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 -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] The case for Markdown (yes, I rtfm)
I think you are misunderstanding what one should document in the fossil wiki. Not at all end user documentation. The documentation I put there is design documentation, application goals/requirements, etc... End user documentation is something totally different that is not at all contained in the Fossil wiki. For me, the Fossil wiki really isn't even of interest to non-developers (users) in any way. My public project page will be in some other format, most likely a CMS system with news, blog, forums, etc... Documentation will be in static HTML most likely that is then displayed in an HTML viewer of a GUI application or hosted on a website with hooks into a web application. The fossil wiki is for developers documenting the development process for me. That's what I use the Fossil wiki for. Jeremy -- From: Will Duquette w...@wjduquette.com Sent: Sunday, November 29, 2009 10:36 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) My two cents on all of this: regardless of what wiki syntax is used, the Fossil Wiki is a lousy way to do your software documentation. You write your software. Ultimately, you deliver your software. Then you want to deliver your documentation *with* your software...and it's in a wiki tied to your CM repository, and you've got a problem. The Fossil wiki is a great way to easily create your project's web pages: development news, installation instructions, download pages, FAQs, and the like. It's great for meta-documentation, and for communication among the development team. Use it for more than that and you're asking for trouble. On Nov 29, 2009, at 6:49 AM, Jeremy Cowgar wrote: Not at all as Markdown, Creole or Textile all look great as plain text. Those without the plugin will simply not have glorified HTML markup but they will still be able to participate. However, I only mentioned this option as some think proper wiki formatting is too much work. My real suggestion would be for fossil to adopt 1 major format as the format to use. Those that wish to use verbose HTML can still do so. Those that wish to have a nice formatting language that's easy to maintain/type/read/understand can use the formatting engine. No one looses. I'm failing to see how such an addition is generating such a vocal attack by a few. It has been mentioned that there will be complaining and arguing to what format to choose and yet there has been none, only those who dislike a format making assumptions as to what will happen. Jeremy From: Michael Richter Sent: Sunday, November 29, 2009 9:36 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) And with this you lose the interoperability of Fossil repositories. Go team. 2009/11/29 Jeremy Cowgar jer...@cowgar.com For those that would like a real human formatting language it would be worth a dependency. For those that prefer to use HTML can simply not link in the library. #ifdef MARKDOWN #include markdown.h #endif ... #ifdef MARKDOWN output = ConvertMarkdown(rawText); #endif ... $ gcc -DMARKDOWN fossil.c -o fossil Pretty easy, eh? Now, that's an over simplification but not by much. Jeremy -- From: Eric e...@deptj.eu Sent: Sunday, November 29, 2009 6:44 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) The number of mails about this just proves that there is no right choice for a new wiki markup. There are plenty of lightweight markup formats out there (with their own enthusiastic followers) that haven't even been mentioned here yet. If you want to do your project documentation a particular way, then do it that way - as project files. The other problem is introducing external dependencies for Fossil - have you noticed how few there are? My vote (somebody else mentioned votes!) is to leave the Fossil wiki alone (except for gradual improvement). Eric ___ 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 ___ 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 -- will -at- wjduquette.com | Catch our
Re: [fossil-users] The case for Markdown (yes, I rtfm)
From: Jeremy Cowgar jer...@cowgar.com Sent: Sunday, November 29, 2009 11:01 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) I think you are misunderstanding what one should document in the fossil wiki. I should have said what I put in the wiki. The wiki can be used for any purpose of course. Jeremy ___ 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] The case for Markdown (yes, I rtfm)
Fair enough. On Nov 29, 2009, at 8:01 AM, Jeremy Cowgar wrote: I think you are misunderstanding what one should document in the fossil wiki. Not at all end user documentation. The documentation I put there is design documentation, application goals/requirements, etc... End user documentation is something totally different that is not at all contained in the Fossil wiki. For me, the Fossil wiki really isn't even of interest to non-developers (users) in any way. My public project page will be in some other format, most likely a CMS system with news, blog, forums, etc... Documentation will be in static HTML most likely that is then displayed in an HTML viewer of a GUI application or hosted on a website with hooks into a web application. The fossil wiki is for developers documenting the development process for me. That's what I use the Fossil wiki for. Jeremy -- From: Will Duquette w...@wjduquette.com Sent: Sunday, November 29, 2009 10:36 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) My two cents on all of this: regardless of what wiki syntax is used, the Fossil Wiki is a lousy way to do your software documentation. You write your software. Ultimately, you deliver your software. Then you want to deliver your documentation *with* your software...and it's in a wiki tied to your CM repository, and you've got a problem. The Fossil wiki is a great way to easily create your project's web pages: development news, installation instructions, download pages, FAQs, and the like. It's great for meta-documentation, and for communication among the development team. Use it for more than that and you're asking for trouble. On Nov 29, 2009, at 6:49 AM, Jeremy Cowgar wrote: Not at all as Markdown, Creole or Textile all look great as plain text. Those without the plugin will simply not have glorified HTML markup but they will still be able to participate. However, I only mentioned this option as some think proper wiki formatting is too much work. My real suggestion would be for fossil to adopt 1 major format as the format to use. Those that wish to use verbose HTML can still do so. Those that wish to have a nice formatting language that's easy to maintain/type/read/understand can use the formatting engine. No one looses. I'm failing to see how such an addition is generating such a vocal attack by a few. It has been mentioned that there will be complaining and arguing to what format to choose and yet there has been none, only those who dislike a format making assumptions as to what will happen. Jeremy From: Michael Richter Sent: Sunday, November 29, 2009 9:36 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) And with this you lose the interoperability of Fossil repositories. Go team. 2009/11/29 Jeremy Cowgar jer...@cowgar.com For those that would like a real human formatting language it would be worth a dependency. For those that prefer to use HTML can simply not link in the library. #ifdef MARKDOWN #include markdown.h #endif ... #ifdef MARKDOWN output = ConvertMarkdown(rawText); #endif ... $ gcc -DMARKDOWN fossil.c -o fossil Pretty easy, eh? Now, that's an over simplification but not by much. Jeremy -- From: Eric e...@deptj.eu Sent: Sunday, November 29, 2009 6:44 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) The number of mails about this just proves that there is no right choice for a new wiki markup. There are plenty of lightweight markup formats out there (with their own enthusiastic followers) that haven't even been mentioned here yet. If you want to do your project documentation a particular way, then do it that way - as project files. The other problem is introducing external dependencies for Fossil - have you noticed how few there are? My vote (somebody else mentioned votes!) is to leave the Fossil wiki alone (except for gradual improvement). Eric ___ 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 ___ 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] The case for Markdown (yes, I rtfm)
The current way to format text blows. There is a divide on which markdown to use. Formatting makes reading text much much better. Solution: Put the top three markdowns in a list. Use a random number generator to pick the markdown language. These large email conversations about markdown* are not in any way an indication that we don't need it.* They are an indication that Fossil does need it. *Anything* is better than plain HTML. ___ 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] The case for Markdown (yes, I rtfm)
One thought that I had was to enable feeding wiki pages through a TCP pipe so that they could be post-processed. That would enable storing the pages in the wiki and rendering the wiki pages completely could be done on any platform that supports a web server. Any wiki markup can be supported and then fossil itself is not dependent on another library. If you don't want to use the extra markup, then don't. If you really feel the need for Markdown, Creole, etc, then it is available. just my 0.02 //Bill On 11/29/2009 06:44 AM, Eric wrote: The number of mails about this just proves that there is no right choice for a new wiki markup. There are plenty of lightweight markup formats out there (with their own enthusiastic followers) that haven't even been mentioned here yet. If you want to do your project documentation a particular way, then do it that way - as project files. The other problem is introducing external dependencies for Fossil - have you noticed how few there are? My vote (somebody else mentioned votes!) is to leave the Fossil wiki alone (except for gradual improvement). Eric ___ 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] The case for Markdown (yes, I rtfm)
On Sun, 2009-11-29 at 08:51 -0800, Kurtis Rainbolt-Greene wrote: There is a divide on which markdown to use. That's just it: there isn't! There are people who say we don't need a markdown-esque formatting (or the minimal one already in fossil is enough), and there are people who want a more complete formatting option *And have steadfastly declined to argue over which one*. A couple of us have said we *prefer* markdown but will happily take any of the existing more complete systems over the existing almost-non-system. I recognize that the improvement I and others are asking for may be non-trivial to implement, so while I think markdown (the particular format, not the general class of) is an obvious choice because it allows those who prefer plain HTML to just keep writing HTML without change, if something else is easier to integrate or otherwise preferable I'll happily embrace it. -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ 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] The case for Markdown (yes, I rtfm)
From: Will Duquette w...@wjduquette.com Date: Sun, November 29, 2009 3:36 pm My two cents on all of this: regardless of what wiki syntax is used, the Fossil Wiki is a lousy way to do your software documentation. You write your software. Ultimately, you deliver your software. Then you want to deliver your documentation *with* your software...and it's in a wiki tied to your CM repository, and you've got a problem. The Fossil wiki is a great way to easily create your project's web pages: development news, installation instructions, download pages, FAQs, and the like. It's great for meta-documentation, and for communication among the development team. Use it for more than that and you're asking for trouble. I wish I'd said that! Eric ___ 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] The case for Markdown (yes, I rtfm)
Q1: 4 YES | 1 APATHETIC | 2 NO Q2: 4 WHATEVER WORKS | 2 HTML | 1 MARKDOWN PS I said this was specifically for my own curiosity, nothing more. Nice try, Zed. On Sun, Nov 29, 2009 at 3:51 PM, Zed A. Shaw zeds...@zedshaw.com wrote: On Sun, Nov 29, 2009 at 05:05:52PM -0600, Kurtis Rainbolt-Greene wrote: Also, Zed challenged me to prove that more people want any kind of (better) formatting than not: http://spreadsheets.google.com/viewform?formkey=dDBVZS1CM0M0akFiSlRtUE5CdUdKa2c6MA There's the form link. I am in no way in control of this or any part of Fossil. I simply want to see for personal curiosity. Yay! Evidence! Hooray! Finally, people can now just vote and then when they're done voting you can dive in and implement it! (I voted BTW.) -- Zed A. Shaw http://zedshaw.com/ ___ 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] The case for Markdown (yes, I rtfm)
Purely out of curiousity, I've glanced at Markdown and Creole, neither of which I've used. The problem with Markdown is that the format as defined simply isn't a Wiki format. It's Wiki-like, but doesn't include the markup for links to wiki pages. (There's some kind of linking, but it isn't wiki- linking.) So if Markdown is used it will be necessary to extend it. There appear to be three C implementations of Markdown; one, which I didn't look at, is only a partial implementation. One, peg-markdown, is apparently profligate of memory use, but is intended to be easily extensible. Another, discount, has an API that (to my casual view) doesn't appear to be tailored for use in a Wiki; changes would be required. How easy it would be to extend, I dunno. Creole, on the other hand, *is* a Wiki syntax, though it's an odd one (**bold**? //italics//? where did *those* come from?) (Yes, I know that the Creole site has the rationale for everything.) However, the list of extant parsers on the Creole web page doesn't include one written in C. At a casual glance, then, neither Markdown nor Creole looks like an easy drop-in replacement for what we have now. (Feel free to prove me wrong; ten minutes of web-browsing doesn't make me any kind of expert.) Will On Nov 29, 2009, at 4:55 PM, Kurtis Rainbolt-Greene wrote: Just to be clear here since there has been some distracting arguments made: There is no bikeshedding being done in this thread. As proof of point a clear major majority do not care what color the bikeshed is (AKA, what format to use) according to my poll. I see two (major) sides of this conversation: 1. People who want better formatting, whatever the result. 2. People who are worried that everyone else is worried about the color of the bikeshed. The only minority are those who are happy with HTML. Since any markdown language allows HTML they really don't factor into this topic. tl;dr quit concern trolling On Sun, Nov 29, 2009 at 4:19 PM, Kurtis Rainbolt-Greene thinkwritem...@gmail.com wrote: Q1: 4 YES | 1 APATHETIC | 2 NO Q2: 4 WHATEVER WORKS | 2 HTML | 1 MARKDOWN PS I said this was specifically for my own curiosity, nothing more. Nice try, Zed. On Sun, Nov 29, 2009 at 3:51 PM, Zed A. Shaw zeds...@zedshaw.com wrote: On Sun, Nov 29, 2009 at 05:05:52PM -0600, Kurtis Rainbolt-Greene wrote: Also, Zed challenged me to prove that more people want any kind of (better) formatting than not: http://spreadsheets.google.com/viewform?formkey=dDBVZS1CM0M0akFiSlRtUE5CdUdKa2c6MA There's the form link. I am in no way in control of this or any part of Fossil. I simply want to see for personal curiosity. Yay! Evidence! Hooray! Finally, people can now just vote and then when they're done voting you can dive in and implement it! (I voted BTW.) -- Zed A. Shaw http://zedshaw.com/ ___ 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 -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] The case for Markdown (yes, I rtfm)
I have not done extensive research either, however, I would say solve the first problem first. 1. Can we extend the wiki to allow better text formatting? 2. If so, what format would we want to implement? 3. Who will do the implementation? 4. --- Now we can look at libraries --- 4a. Is there a suitable library? How will it integrate? 4b. Do we need to develop our own? Can it be done reasonably in small stages, I.e. bold, italic, typewriter type in one stage. Later lists/nested lists/numbered lists, Later tables, etc... I.e. does it have to be done all at once or can we slowly add to it as time permits. I think researching a library first is the wrong way to go about it. It may be that there is no suitable library, but does that then mean that the need doesn't exist? There may be a suitable library but the idea of a dependency scares everyone off so maybe we need a C source file that does the formatting and can be added too slowly, etc... Jeremy -- From: Will Duquette w...@wjduquette.com Sent: Sunday, November 29, 2009 9:15 PM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) Purely out of curiousity, I've glanced at Markdown and Creole, neither of which I've used. The problem with Markdown is that the format as defined simply isn't a Wiki format. It's Wiki-like, but doesn't include the markup for links to wiki pages. (There's some kind of linking, but it isn't wiki- linking.) So if Markdown is used it will be necessary to extend it. There appear to be three C implementations of Markdown; one, which I didn't look at, is only a partial implementation. One, peg-markdown, is apparently profligate of memory use, but is intended to be easily extensible. Another, discount, has an API that (to my casual view) doesn't appear to be tailored for use in a Wiki; changes would be required. How easy it would be to extend, I dunno. Creole, on the other hand, *is* a Wiki syntax, though it's an odd one (**bold**? //italics//? where did *those* come from?) (Yes, I know that the Creole site has the rationale for everything.) However, the list of extant parsers on the Creole web page doesn't include one written in C. At a casual glance, then, neither Markdown nor Creole looks like an easy drop-in replacement for what we have now. (Feel free to prove me wrong; ten minutes of web-browsing doesn't make me any kind of expert.) Will On Nov 29, 2009, at 4:55 PM, Kurtis Rainbolt-Greene wrote: Just to be clear here since there has been some distracting arguments made: There is no bikeshedding being done in this thread. As proof of point a clear major majority do not care what color the bikeshed is (AKA, what format to use) according to my poll. I see two (major) sides of this conversation: 1. People who want better formatting, whatever the result. 2. People who are worried that everyone else is worried about the color of the bikeshed. The only minority are those who are happy with HTML. Since any markdown language allows HTML they really don't factor into this topic. tl;dr quit concern trolling On Sun, Nov 29, 2009 at 4:19 PM, Kurtis Rainbolt-Greene thinkwritem...@gmail.com wrote: Q1: 4 YES | 1 APATHETIC | 2 NO Q2: 4 WHATEVER WORKS | 2 HTML | 1 MARKDOWN PS I said this was specifically for my own curiosity, nothing more. Nice try, Zed. On Sun, Nov 29, 2009 at 3:51 PM, Zed A. Shaw zeds...@zedshaw.com wrote: On Sun, Nov 29, 2009 at 05:05:52PM -0600, Kurtis Rainbolt-Greene wrote: Also, Zed challenged me to prove that more people want any kind of (better) formatting than not: http://spreadsheets.google.com/viewform?formkey=dDBVZS1CM0M0akFiSlRtUE5CdUdKa2c6MA There's the form link. I am in no way in control of this or any part of Fossil. I simply want to see for personal curiosity. Yay! Evidence! Hooray! Finally, people can now just vote and then when they're done voting you can dive in and implement it! (I voted BTW.) -- Zed A. Shaw http://zedshaw.com/ ___ 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 -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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
Re: [fossil-users] The case for Markdown (yes, I rtfm)
Some of the e-mails in this thread today made it sound like it would be an easy thing to just drop one of these formats in; or, at least, so I interpreted them. As someone noted, a little data is a useful thing, so I went and found some. Understand, I'm not advocating for any result in particular. On the one hand, I wouldn't object to a richer markup language; on the other, I don't really need it; and I don't much care what gets picked. By choice I'd prefer something similar to poortext, the markup used by my Notebook app, but it doesn't have a C implementation either, and nothing but Notebook uses it. Markdown looks fine so far as it goes (which isn't quite far enough); Creole looks weird; Wikipedia's markup is certainly functional, and widely used. Will On Nov 29, 2009, at 6:25 PM, Jeremy Cowgar wrote: I have not done extensive research either, however, I would say solve the first problem first. 1. Can we extend the wiki to allow better text formatting? 2. If so, what format would we want to implement? 3. Who will do the implementation? 4. --- Now we can look at libraries --- 4a. Is there a suitable library? How will it integrate? 4b. Do we need to develop our own? Can it be done reasonably in small stages, I.e. bold, italic, typewriter type in one stage. Later lists/ nested lists/numbered lists, Later tables, etc... I.e. does it have to be done all at once or can we slowly add to it as time permits. I think researching a library first is the wrong way to go about it. It may be that there is no suitable library, but does that then mean that the need doesn't exist? There may be a suitable library but the idea of a dependency scares everyone off so maybe we need a C source file that does the formatting and can be added too slowly, etc... Jeremy -- From: Will Duquette w...@wjduquette.com Sent: Sunday, November 29, 2009 9:15 PM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The case for Markdown (yes, I rtfm) Purely out of curiousity, I've glanced at Markdown and Creole, neither of which I've used. The problem with Markdown is that the format as defined simply isn't a Wiki format. It's Wiki-like, but doesn't include the markup for links to wiki pages. (There's some kind of linking, but it isn't wiki- linking.) So if Markdown is used it will be necessary to extend it. There appear to be three C implementations of Markdown; one, which I didn't look at, is only a partial implementation. One, peg-markdown, is apparently profligate of memory use, but is intended to be easily extensible. Another, discount, has an API that (to my casual view) doesn't appear to be tailored for use in a Wiki; changes would be required. How easy it would be to extend, I dunno. Creole, on the other hand, *is* a Wiki syntax, though it's an odd one (**bold**? //italics//? where did *those* come from?) (Yes, I know that the Creole site has the rationale for everything.) However, the list of extant parsers on the Creole web page doesn't include one written in C. At a casual glance, then, neither Markdown nor Creole looks like an easy drop-in replacement for what we have now. (Feel free to prove me wrong; ten minutes of web-browsing doesn't make me any kind of expert.) Will On Nov 29, 2009, at 4:55 PM, Kurtis Rainbolt-Greene wrote: Just to be clear here since there has been some distracting arguments made: There is no bikeshedding being done in this thread. As proof of point a clear major majority do not care what color the bikeshed is (AKA, what format to use) according to my poll. I see two (major) sides of this conversation: 1. People who want better formatting, whatever the result. 2. People who are worried that everyone else is worried about the color of the bikeshed. The only minority are those who are happy with HTML. Since any markdown language allows HTML they really don't factor into this topic. tl;dr quit concern trolling On Sun, Nov 29, 2009 at 4:19 PM, Kurtis Rainbolt-Greene thinkwritem...@gmail.com wrote: Q1: 4 YES | 1 APATHETIC | 2 NO Q2: 4 WHATEVER WORKS | 2 HTML | 1 MARKDOWN PS I said this was specifically for my own curiosity, nothing more. Nice try, Zed. On Sun, Nov 29, 2009 at 3:51 PM, Zed A. Shaw zeds...@zedshaw.com wrote: On Sun, Nov 29, 2009 at 05:05:52PM -0600, Kurtis Rainbolt-Greene wrote: Also, Zed challenged me to prove that more people want any kind of (better) formatting than not: http://spreadsheets.google.com/viewform?formkey=dDBVZS1CM0M0akFiSlRtUE5CdUdKa2c6MA There's the form link. I am in no way in control of this or any part of Fossil. I simply want to see for personal curiosity. Yay! Evidence! Hooray! Finally, people can now just vote and then when they're done voting you can dive in and implement it! (I voted BTW.) -- Zed A. Shaw http://zedshaw.com
Re: [fossil-users] The case for Markdown (yes, I rtfm)
On Sun, Nov 29, 2009 at 04:19:02PM -0800, Kurtis Rainbolt-Greene wrote: Q1: 4 YES | 1 APATHETIC | 2 NO Q2: 4 WHATEVER WORKS | 2 HTML | 1 MARKDOWN PS I said this was specifically for my own curiosity, nothing more. Nice try, Zed. Now now, you can't stop it when you want. To keep you honest you have to leave it up for 24 hours, otherwise you'll end the voting at whatever point is convenient for you. -- Zed A. Shaw http://zedshaw.com/ ___ 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] The case for Markdown (yes, I rtfm)
I'm not going to bother stopping it, nor did I plan to. I was only showing you what the first 10m showed. Now? YES: 13 NO: 3 Any: 13 Markdown: 3 Creole: 1 On Sun, Nov 29, 2009 at 7:26 PM, Zed A. Shaw zeds...@zedshaw.com wrote: On Sun, Nov 29, 2009 at 04:19:02PM -0800, Kurtis Rainbolt-Greene wrote: Q1: 4 YES | 1 APATHETIC | 2 NO Q2: 4 WHATEVER WORKS | 2 HTML | 1 MARKDOWN PS I said this was specifically for my own curiosity, nothing more. Nice try, Zed. Now now, you can't stop it when you want. To keep you honest you have to leave it up for 24 hours, otherwise you'll end the voting at whatever point is convenient for you. -- Zed A. Shaw http://zedshaw.com/ ___ 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
