Re: [fossil-users] The future of markdown-in-fossil
Hello, on Monday 30 July 2012 at 18:53, Stephan Beal wrote: On Mon, Jul 30, 2012 at 10:41 AM, Natacha Porté nata...@instinctive.euwrote: What remains to do: + review my code to ensure it meets fossil level of quality, + format it using fossil code style if needed, + any other code change that comes up during the review. i will be happy to offer my 0.0163 Euros, but i won't be able to do so until later in the week. Richard is, from what i understand, swamped for the foreseeable future. Of course, anyone else is encouraged to help :). While i don't personally use MD i'd like to see it added if only because people keep asking about it ;). Maybe then some of the religious wars can end ;). [...] To be clear: the final decision about what goes in to the trunk belongs to Richard and Richard alone. The other contributors, such as a myself, are here to assist, but the final decision rests with him. For what i'd worth, i'd like to see it included (but would like to look at the code first ;). I was just wondering whether I have been missing something. Would you or anyone from the list confirm whether at this point I only have to wait for Richard's review and approval, or is there something I forgot to perform before that can happen? Thanks for your help, Natacha Porté pgpEntNcAgmvh.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] The future of markdown-in-fossil
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/2012 10:46 AM, Jan Danielsson wrote: On 08/03/12 15:42, Stephan Beal wrote: [---] Another consideration here is that the wiki has kind of fallen out of use, [---] I don't know that that is true. The only proof of this I have seen prior to this thread is that at times it's mentioned that the fossil repository uses embedded wiki rather than the built in wiki. Hear hear. All that means is that wikis aren't the best way of handling documentation for an open source project; it is indeed better to version documents as part of the source code tree. However, wikis are ideal for user-contributed material that's attached to an open-source project, and documents relating to that project with a scope beyond a particular revision of the project itself. Also, wikis are editable in the browser, making them far more accessible for contribution than embedded documentation. I have a fossil repo for my house. The wiki is served up from the home fileserver and contains recipies, useful information for visitors, and stuff like that. I have tickets for DIY projects and things we need to buy. And the filesystem repo contains important documents pertaining to the house. I've set up web permissions so that only logged-in users can get beyond the wiki. On the other hand, my open source projects at http://www.kitten-technologies.co.uk/ are all cgi-hosted Fossil repos (the front site itself is static HTML, but generated from stuff in a fossil repo - see http://www.kitten-technologies.co.uk/project/kitten-technologies and a typical project such as http://www.kitten-technologies.co.uk/project/ugarit), all heavily based around embedded documentation; I'll do things with the inbuilt wiki if a user community develops around any of them and non-contributors seem to want to contribute stuff! ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAhJ5kACgkQRgz/WHNxCGqk5gCfdlORZHYj1qJ2aWMMCHI8Tbcc F9YAn2eR8n+sWgPpHaUmIpVW2pSlpBkf =lBZf -END 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 future of markdown-in-fossil
On Tue, Aug 7, 2012 at 4:35 PM, Alaric Snell-Pym ala...@snell-pym.org.ukwrote: I have a fossil repo for my house. The wiki is served up from the home... i'm willing to bet that that's a use case none of us foresaw. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
On 08/03/12 15:42, Stephan Beal wrote: [---] Another consideration here is that the wiki has kind of fallen out of use, [---] I don't know that that is true. The only proof of this I have seen prior to this thread is that at times it's mentioned that the fossil repository uses embedded wiki rather than the built in wiki. For my part, I use the built in editor/wiki command line on a daily basis, and it would sadden me greatly if it is depreciated, or if someone would scrap any ideas of enhancements to it due to the perceived notion that no one uses it any more. ...that said, I realize I could be the only one still using it. :) The embedded wiki is useful for pages which are versioned. But there are lots of things which I write which principally aren't meant to be versioned, such as wide-perspective project goals, code conventions, security considerations, protocol requirements, etc. Things which are true in the past, present and future. I also have a central repository on a server which serves as reference pages (I collect notes on administration of things I very rarely do, cool/useful shell tricks, etc), and it would be too much hassle to use the embedded wiki system for that. While I'm anyways on the topic of things which worry me a little.. I travel by train a lot, and on the train I don't always have access to an electrical socket, so I run the laptop on battery. For this reason I often run without X (I want as good battery time as possible). Now, I don't want to come off as one of those got off my lawn, you kids! types, so I'll be very explicit: I'm 100% for all the AJAX:ish work being done and considered. It adds a lot of value to the users (including myself), so it should be there and continue to be worked on. That being said, I want to (as far as possible) be able to do what I do with fossil at home even when I'm working on the train, in console mode. This is the primary reason I would want markdown support (in the built-in wiki and ticket system): I think it's easier to read/parse (mentally) and write than any wiki syntax I've seen so far. And even if we get a nice WYSIWYG editor for the web interface (in theory rendering the stored format irrelevant), I'll still be sitting writing wiki documents on the train in plain old vim, because there really isn't any other option. -- Kind regards, Jan Danielsson signature.asc Description: OpenPGP digital 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 future of markdown-in-fossil
On Mon, Aug 6, 2012 at 11:46 AM, Jan Danielsson jan.m.daniels...@gmail.comwrote: For my part, I use the built in editor/wiki command line on a daily basis, and it would sadden me greatly if it is depreciated, or if someone would scrap any ideas of enhancements to it due to the perceived notion that no one uses it any more. ...that said, I realize I could be the only one still using it. :) Sorry, i didn't mean to imply that it was being deprecated. It is one of fossil's core features, and it DOES get used by many people, but not so much in the fossil project itself. (In fact, the wiki and CGI is what originally caught my eye in fossil.) The embedded wiki is useful for pages which are versioned. But there are lots of things which I write which principally aren't meant to be ...etc), and it would be too much hassle to use the embedded wiki system for that. It's certainly more convenient for that type of thing. While I'm anyways on the topic of things which worry me a little.. No worries - wiki is there to stay. Even if we wanted to (which we don't!), removing it would be a huge compatibility problem and would upset probably 30-50% of the users pretty badly ;). That being said, I want to (as far as possible) be able to do what I do with fossil at home even when I'm working on the train, in console mode. fossil wiki export ... fossil wiki commit ... we get a nice WYSIWYG editor for the web interface (in theory rendering the stored format irrelevant), I'll still be sitting writing wiki documents on the train in plain old vim, because there really isn't any other option. We DO have a wysiwyg editor on the list of todos, but it is pending the custom pages support because that support will include the infrastructure we need for serving the editor. i've been tinkering with the custom pages/commands support for 3-4 weeks now, but with my current approach (based on TH1) i keep running into a wall regarding what types of things we can reasonably do with th1. Over the weekend i had a nice chat with Joe Mistachkin about TCL, and i think the only reasonable way to do custom pages/commands (that is, without having to castrate them unduly) is to use his TCL support. Anwyay... -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
* Stephan Beal sgb...@googlemail.com [20120803 15:34]: Another consideration here is that the wiki has kind of fallen out of use, with the embedded docs system generally being preferred. While i admit that i pay a good deal of attention to fossil's wiki API (i've added several of the wiki subcommands and the wiki API was amongst the first of the JSON APIs added), i will admit that embedded docs are generally a better solution. But the wiki is just too convenient (which is the only reason anyone really uses a wiki, anyway). Once i get embedded docs support in the JSON API, i probably won't touch the wiki API again. I believe you are underestimating the built-in wiki. As I see it is one of fossil's killer features: my use case is a dramatically lower barrier to entry for non-developers contributing to a non-distributed repo. qvb -- pica ___ 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 future of markdown-in-fossil
On Sat, Aug 4, 2012 at 1:22 PM, Joan Picanyol i Puig lists-fos...@biaix.org wrote: I believe you are underestimating the built-in wiki. As I see it is one of fossil's killer features: my use case is a dramatically lower barrier to entry for non-developers contributing to a non-distributed repo. In fact the wiki and CGI support were what got me so interested in the first place. i still use the wiki, but for longer-term doc management the embedded docs provide better support (e.g. the ability to edit/preview them using /doc/ckout/..., plus full versioning and branching). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
Hello, on Monday 30 July 2012 at 18:53, Stephan Beal wrote: On Mon, Jul 30, 2012 at 10:41 AM, Natacha Porté nata...@instinctive.euwrote: What remains to do: + review my code to ensure it meets fossil level of quality, + format it using fossil code style if needed, + any other code change that comes up during the review. i will be happy to offer my 0.0163 Euros, but i won't be able to do so until later in the week. Richard is, from what i understand, swamped for the foreseeable future. No problem at all, I'm genuinely that patient. You could tell me nobody would have time to look at it in 2012, and that would be fine with me and I wouldn't send any other reminder before end of Januray 2013. Of course, anyone else is encouraged to help :). Indeed, all constructive criticism about my code is always welcome, even if the code turns out to be eventually rejected. That's how I have always been able to make any progress in my programming skills. While i don't personally use MD i'd like to see it added if only because people keep asking about it ;). Maybe then some of the religious wars can end ;). And some other can start, for example which superset of Markdown to settle for :-) And this is only half a joke, since raw Markdown is quite limited, and its inventor refuses any further evolution. So most software actually supports a kind of extended Markdown, but there is little consistency in the exact set of extensions. It's Babel all over again. I didn't mention that as an open question, because that will be moot if the library is rejected, but before having a real markdowned-fossil release the question will have to be answered. i will post back once i have looked over it. Would you prefer that i send comments regarding it to the list or to you directly? I don't have any preference in that regard, either way suits me as well. So I guess it boils down to whether the rest of the list is interested in such comments or whether they would rather avoid the extra spam. And thank you for your contribution and persistence. Sure :-) And thank you for the heartwarming answer ^^ Still, I'm never sure where is the line between persistence as a good trait and persistence as a bad one. I hope I haven't crossed it yet. To be clear: the final decision about what goes in to the trunk belongs to Richard and Richard alone. The other contributors, such as a myself, are here to assist, but the final decision rests with him. For what i'd worth, i'd like to see it included (but would like to look at the code first ;). Of course, that's as much as I expected. I consider any comment on my code I get from here as a privilege. Thanks for your interest, Natacha Porté pgpDlRV7mKtu0.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] The future of markdown-in-fossil
On 3 August 2012 11:23, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Jul 30, 2012, at 19:43 , Gautier DI FOLCO wrote: 2012/7/30 Bill Burdick bill.burd...@gmail.com I'd like to see it included, as well! I'd like it too, it will be easier for beginnes (like me!). +1 Why markdown and not one of the dozens of other wiki syntaxes? I don't find wiki syntaxes really easy. Maybe a bit easier to type than HTML but definitely not easy to read or remember, especially since there are dozens of slightly (and not so slightly) different variants. Note there are JavaScript hacks for interpreting random wiki syntax so you can have markdown interpreted without any direct support in fossil. Thanks Michal ___ 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 future of markdown-in-fossil
On Aug 3, 2012, at 11:53 , Michal Suchanek wrote: On 3 August 2012 11:23, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: +1 Why markdown and not one of the dozens of other wiki syntaxes? Because markdown is a very popular one, used by github, and we have on board the creator of a major implementation (the one used by github, iirc). I don't find wiki syntaxes really easy. Maybe a bit easier to type than HTML but definitely not easy to read or remember, especially since there are dozens of slightly (and not so slightly) different variants. That's why half of the web seems to standarize on markdown. The same web that was mostly writing HTML a few years ago. Note there are JavaScript hacks for interpreting random wiki syntax so you can have markdown interpreted without any direct support in fossil. Note there are good wiki engines out there, so no need for one in Fossil too. But once we set the scope to include something, please don't keep it half-hearted... Kind regards, Remigiusz Modrzejewski ___ 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 future of markdown-in-fossil
On 3 August 2012 12:07, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Aug 3, 2012, at 11:53 , Michal Suchanek wrote: On 3 August 2012 11:23, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: +1 Why markdown and not one of the dozens of other wiki syntaxes? Because markdown is a very popular one, used by github, and we have on board the creator of a major implementation (the one used by github, iirc). The others are also very popular. Github has a cute logo but I would not turn to it when looking for sound technical solutions. I don't find wiki syntaxes really easy. Maybe a bit easier to type than HTML but definitely not easy to read or remember, especially since there are dozens of slightly (and not so slightly) different variants. That's why half of the web seems to standarize on markdown. The same web that was mostly writing HTML a few years ago. Does not seem that way to me. I deal with sites using various wiki format variations. If you want to make your point on that then supply more data, please. Note there are JavaScript hacks for interpreting random wiki syntax so you can have markdown interpreted without any direct support in fossil. Note there are good wiki engines out there, so no need for one in Fossil too. But once we set the scope to include something, please don't keep it half-hearted... And it has been said that markdown is out of the scope of Fossil. I am not to decide that but I have to agree. Once you let in markdown people used to some other wiki syntax would argue they have needlessly hard time and there would be no end to the stream of requests to include yet another. Thanks Michal ___ 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 future of markdown-in-fossil
On Aug 3, 2012, at 12:19 , Michal Suchanek wrote: Why markdown and not one of the dozens of other wiki syntaxes? Because markdown is a very popular one, used by github, and we have on board the creator of a major implementation (the one used by github, iirc). Github has a cute logo but I would not turn to it when looking for sound technical solutions. Still, somehow, they don't seem a failure. A cute logo can't buy that... That's why half of the web seems to standarize on markdown. The same web that was mostly writing HTML a few years ago. Does not seem that way to me. I deal with sites using various wiki format variations. If you want to make your point on that then supply more data, please. No data. Just the anecdotal: a few years ago most input fields I've hit on the web accepted sanitized HTML, now they take markdown. Yeah, they're usually not wikis (but the wiki engine I use actually uses markdown). Note there are JavaScript hacks for interpreting random wiki syntax so you can have markdown interpreted without any direct support in fossil. Note there are good wiki engines out there, so no need for one in Fossil too. But once we set the scope to include something, please don't keep it half-hearted... And it has been said that markdown is out of the scope of Fossil. I am not to decide that but I have to agree. Once you let in markdown people used to some other wiki syntax would argue they have needlessly hard time and there would be no end to the stream of requests to include yet another. I've read the we'll have requests for all the markups in the world argument many times. I can't remember anyone actually coming and asking for *anything* else than markdown. Kind regards, Remigiusz Modrzejewski ___ 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 future of markdown-in-fossil
On 3 August 2012 12:26, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: Note there are JavaScript hacks for interpreting random wiki syntax so you can have markdown interpreted without any direct support in fossil. Note there are good wiki engines out there, so no need for one in Fossil too. But once we set the scope to include something, please don't keep it half-hearted... And it has been said that markdown is out of the scope of Fossil. I am not to decide that but I have to agree. Once you let in markdown people used to some other wiki syntax would argue they have needlessly hard time and there would be no end to the stream of requests to include yet another. I've read the we'll have requests for all the markups in the world argument many times. I can't remember anyone actually coming and asking for *anything* else than markdown. That may also prove only that markdown proponents are noisy and inconsiderate. Project X should have markdown because it is what I am familiar with and it seems to me the best and most widespread syntax, meh. Regards Michal ___ 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 future of markdown-in-fossil
Hello, On Aug 3, 2012, at 11:53 , Michal Suchanek wrote: Why markdown and not one of the dozens of other wiki syntaxes? If I understand correctly this question wasn't addressed to me (as a developer of the markdown-in-fossil code) but I'll try to contribute as objectively as I can. As a user, the killer feature I see for markdown is that the implementation exists (assuming my code is considered worthy, which is quite a strong assumption, but without it everything else is moot anyway, so I'll keep the assumption in this e-mail). Code that exists wins over code that does not. We can discuss for days about the best markup syntax, it's completely useless when there is nobody to actually implement it. Of course, I would welcome other propositions of implementation, and I would still be glad if my code was rejected in favor of another implementation (of markdown or of another lightweight markup language that I prefer to the current wiki syntax). Now my personal opinion about markdown is probably of no interest to anybody else, but while I do have strong objections and dislikings about it, I haven't encountered any other lightweight markup syntax with which I have more affinity. Useless, isn't it? on Friday 03 August 2012 at 12:19, Michal Suchanek wrote: And it has been said that markdown is out of the scope of Fossil. I don't know about that. And honestly, I'm glad I don't have to make that call. I am not to decide that but I have to agree. Once you let in markdown people used to some other wiki syntax would argue they have needlessly hard time and there would be no end to the stream of requests to include yet another. I think it's very useful to distinguish between requests to write code in order to include yet another, and requests to officially mirror a branch containing ready-to-use code that includes yet another. Surely the stream of the second kind of requests would be much lighter than the stream of the first kind, wouldn't it? And as far as requests of the second kind goes, if the code is good enough and does not bloat the project, why not accept them? (in the context that assumes markdown has already been let in) Thanks for your criticism, Natacha Porté pgpyROnFPGls6.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] The future of markdown-in-fossil
On 3 August 2012 13:04, Natacha Porté nata...@instinctive.eu wrote: Hello, On Aug 3, 2012, at 11:53 , Michal Suchanek wrote: Why markdown and not one of the dozens of other wiki syntaxes? If I understand correctly this question wasn't addressed to me (as a developer of the markdown-in-fossil code) but I'll try to contribute as objectively as I can. As a user, the killer feature I see for markdown is that the implementation exists (assuming my code is considered worthy, which is quite a strong assumption, but without it everything else is moot anyway, so I'll keep the assumption in this e-mail). Code that exists wins over code that does not. We can discuss for days about the best markup syntax, it's completely useless when there is nobody to actually implement it. By the extension of this very argument, code that exists in-tree beats code that exists out of tree. So the current syntax wins. Of course, I would welcome other propositions of implementation, and I would still be glad if my code was rejected in favor of another implementation (of markdown or of another lightweight markup language that I prefer to the current wiki syntax). Now my personal opinion about markdown is probably of no interest to anybody else, but while I do have strong objections and dislikings about it, I haven't encountered any other lightweight markup syntax with which I have more affinity. Useless, isn't it? I have strong objections about all such makups, none is perfect, all have some annoyances, and they are all mutually incompatible. Changing from one to another does not improve things, however. It only brings incompatible repositories into existence. I have looked up the markdown syntax on wikipedia and while it removes some annoyances of the more traditional wiki syntaxes like moinmoin or mediawiki it can do that only at the cost of mutual incompatibility. Interestingly, being a github user I am not familiar with the markdown syntax although github supposedly uses it. Admittedly I have used more moinmoin wikis, mediawikis, and phpbbs than githubs, both in total and each separately. Consider bbcode, too. It is not only familiar to developers but it is even more ancient and more widespread than any wiki syntax, and many non-developers use it. And all of these markups are mutually incompatible. Unless you are willing to implement a plugin engine with plugins for 3-4 most widespread markups there is no way to really improve over what there is now. You will also have to change the format of the database so that it contains an additional field for text artifacts like tickets so that they can be rendered with the correct plugin. on Friday 03 August 2012 at 12:19, Michal Suchanek wrote: And it has been said that markdown is out of the scope of Fossil. I don't know about that. And honestly, I'm glad I don't have to make that call. I am not to decide that but I have to agree. Once you let in markdown people used to some other wiki syntax would argue they have needlessly hard time and there would be no end to the stream of requests to include yet another. I think it's very useful to distinguish between requests to write code in order to include yet another, and requests to officially mirror a branch containing ready-to-use code that includes yet another. Surely the stream of the second kind of requests would be much lighter than the stream of the first kind, wouldn't it? And as far as requests of the second kind goes, if the code is good enough and does not bloat the project, why not accept them? (in the context that assumes markdown has already been let in) Because of compatibility with existing repositories that use the current syntax which is not compatible with markdown. As you did not include a link to your repository of markdown enabled fossil I cannot tell how it addresses compatibility. Thanks Michal ___ 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 future of markdown-in-fossil
Hello, on Friday 03 August 2012 at 13:41, Michal Suchanek wrote: On 3 August 2012 13:04, Natacha Porté nata...@instinctive.eu wrote: As a user, the killer feature I see for markdown is that the implementation exists (assuming my code is considered worthy, which is quite a strong assumption, but without it everything else is moot anyway, so I'll keep the assumption in this e-mail). Code that exists wins over code that does not. We can discuss for days about the best markup syntax, it's completely useless when there is nobody to actually implement it. By the extension of this very argument, code that exists in-tree beats code that exists out of tree. So the current syntax wins. Indeed. And that's the only reason I've ever used it. But now, on the binaries I use, both exist. So as far as I'm concerned, they are both as accessible, and the tie is broken by my preference on Markdown. And the only reason I'm posting to this list is to propose such a situation to anyone interested. I have strong objections about all such makups, none is perfect, all have some annoyances, and they are all mutually incompatible. Changing from one to another does not improve things, however. It only brings incompatible repositories into existence. You're going much further than I am here. What I have proposed does not introduce any incompatibility at all. I have only included the markdown engine and used it for inline (embedded doc) rendering of .mkd and .markdown files in the repository. As I have said elsewhere, I'm not clever enough to imagine a solution to introduce markdown into fossil's internal wiki. So I don't propose it. I propose the extra embedded doc rendering, and the tools to perform any markdown-to-html conversion. When someone comes up with a way to deal with the internal wiki, they will have such tools. I am not to decide that but I have to agree. Once you let in markdown people used to some other wiki syntax would argue they have needlessly hard time and there would be no end to the stream of requests to include yet another. I think it's very useful to distinguish between requests to write code in order to include yet another, and requests to officially mirror a branch containing ready-to-use code that includes yet another. Surely the stream of the second kind of requests would be much lighter than the stream of the first kind, wouldn't it? And as far as requests of the second kind goes, if the code is good enough and does not bloat the project, why not accept them? (in the context that assumes markdown has already been let in) Because of compatibility with existing repositories that use the current syntax which is not compatible with markdown. Well remember that I assumed markdown already in, and therefore this objection already correctly addressed. So that does not qualifies as a reason to not accept further code. As you did not include a link to your repository of markdown enabled fossil I cannot tell how it addresses compatibility. I did. In the very first post of this thread. Natacha Porté pgptKo5tlfz7o.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] The future of markdown-in-fossil
On Fri, 3 Aug 2012 12:19:01 +0200 Michal Suchanek hramr...@gmail.com wrote: Why markdown and not one of the dozens of other wiki syntaxes? Because markdown is a very popular one, used by github, and we have on board the creator of a major implementation (the one used by github, iirc). The others are also very popular. Github has a cute logo but I would not turn to it when looking for sound technical solutions. Stackoverflow and all the sites under its umbrella, and all the sites using this engine, use (modified) markdown syntax [1], [2]. I, for one, while not being a special fan of markdown syntax (to me, the best sytnax I ever had to deal with was that used by wiki.tcl.tk), still think that the proliferation of wiki markups place everyone in position where one just can pick a syntax to use almost at random. Markdown is a) popular; b) has a (seemingly) sound C library implementation. Hence to me it looks like a perfect choice for a project like Fossil. [...] 1. http://blog.stackoverflow.com/2009/10/markdown-one-year-later/ 2. http://stackoverflow.com/editing-help/ ___ 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 future of markdown-in-fossil
On Fri, Aug 3, 2012 at 10:39 AM, Natacha Porté nata...@instinctive.euwrote: No problem at all, I'm genuinely that patient. You could tell me nobody would have time to look at it in 2012, and that would be fine with me and I wouldn't send any other reminder before end of Januray 2013. No, no, you've been exceedingly patient and politely persistent, and a review is on my list for tonight/tomorrow :). if the code turns out to be eventually rejected. That's how I have always been able to make any progress in my programming skills. That's a health world-view in my experience :). And some other can start, for example which superset of Markdown to settle for :-) LOL - yes, i saw a bit of that starting in one of the responses. And this is only half a joke, since raw Markdown is quite limited, and its inventor refuses any further evolution. So most software actually supports a kind of extended Markdown, but there is little consistency in the exact set of extensions. It's Babel all over again. Another argument for just sticking with plain HTML ;). i will post back once i have looked over it. Would you prefer that i send comments regarding it to the list or to you directly? I don't have any preference in that regard, either way suits me as well. So I guess it boils down to whether the rest of the list is interested in such comments or whether they would rather avoid the extra spam. If you are on the fossil-dev list i can send them there (most people on this list aren't interested in geeky details, i think). Still, I'm never sure where is the line between persistence as a good trait and persistence as a bad one. I hope I haven't crossed it yet. Not at all (at least not in my opinion). i'll start feeding back code comments in the next 24 hours or so. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
On 3 August 2012 14:02, Natacha Porté nata...@instinctive.eu wrote: Hello, on Friday 03 August 2012 at 13:41, Michal Suchanek wrote: I have strong objections about all such makups, none is perfect, all have some annoyances, and they are all mutually incompatible. Changing from one to another does not improve things, however. It only brings incompatible repositories into existence. You're going much further than I am here. What I have proposed does not introduce any incompatibility at all. I have only included the markdown engine and used it for inline (embedded doc) rendering of .mkd and .markdown files in the repository. As I have said elsewhere, I'm not clever enough to imagine a solution to introduce markdown into fossil's internal wiki. So I don't propose it. I propose the extra embedded doc rendering, and the tools to perform any markdown-to-html conversion. When someone comes up with a way to deal with the internal wiki, they will have such tools. Well, then it is less than satisfactory solution. HTML is formatted in the browser. Hence support for HTML documents comes for free, with no code required. It is passed through as any other file type. The fossil wiki syntax is used in tickets and internal wiki anyway so documents in that syntax come nearly for free. The only concern is proper hyperlink resolution so that you can browse the site. Users need to know the format for the tickets and internal wiki anyway, and you have cutpaste between docs and and wiki and tickets. Now enter .mkd files. They need additional code to parse, there is no such nice integration with the rest of the fossil, and they do not solve the issue of I am not familiar with this for the users familiar with the other formats. And given somebody wrote a bbcode parser implementation, moin moin parser implementation, and a half dozen others which will be allowed in the fossil proper? Or is parser for any random format to be added? How large will fossil then become? Who will maintain all this? Is the parser to be removed again when the original author is no longer interested and no other maintainer for it steps up? As you did not include a link to your repository of markdown enabled fossil I cannot tell how it addresses compatibility. I did. In the very first post of this thread. Sorry, only saw some replies, not the starting post. Thanks Michal ___ 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 future of markdown-in-fossil
On Fri, Aug 3, 2012 at 12:19 PM, Michal Suchanek ...not to decide that but I have to agree. Once you let in markdown people used to some other wiki syntax would argue they have needlessly hard time and there would be no end to the stream of requests to include yet another. Hi Michal, For what it's worth (i'm summarizing here because i suspect that you missed the past 37302 threads on this topic ;)... Yes, you are absolutely correct (IMO) on each of your points. The fact is, however, that MD support has probably been the single most-requested feature (possibly as a side-effect of github?) in terms of fossil's wiki support. That gives it a bit more weight, in my opinion (even though i don't personally like MD). That said: in several of my fossil wikis i store Google Code format in the wiki and render it client-side. My only point there is that it _is_ currently possible to integrate any wiki format(s) you want to as long as you can render them client-side, and if you are using multiple formats you need a way of differentiating them (so you know which rendered to use), e.g. via a naming convention or a special markup tag in the first line, or similar. Here's an example which uses GoCo format exclusively: http://fossil.wanderinghorse.net/wikis/cson/ (That doesn't look much like Fossil as you know it, but it is a custom UI implemented on top of the JSON API.) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
On Fri, Aug 3, 2012 at 2:56 PM, Michal Suchanek hramr...@gmail.com wrote: And given somebody wrote a bbcode parser implementation, moin moin parser implementation, and a half dozen others which will be allowed in the fossil proper? Or is parser for any random format to be added? And now i KNOW you missed the previous thousand threads ;). No other impls have been added, largely for the reasons you suggest: maintenance, bloat, and general acceptance. MD, however, seems to have had the most/loudest proponents the past few years. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
On 3 August 2012 14:40, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Fri, 3 Aug 2012 12:19:01 +0200 Michal Suchanek hramr...@gmail.com wrote: Why markdown and not one of the dozens of other wiki syntaxes? Because markdown is a very popular one, used by github, and we have on board the creator of a major implementation (the one used by github, iirc). The others are also very popular. Github has a cute logo but I would not turn to it when looking for sound technical solutions. Stackoverflow and all the sites under its umbrella, and all the sites using this engine, use (modified) markdown syntax [1], [2]. So again a somewhat slightly incompatible variation. And there are many using moinmoin or similar syntax, and many using bbcode, and there are probably others in wide use already. I, for one, while not being a special fan of markdown syntax (to me, the best sytnax I ever had to deal with was that used by wiki.tcl.tk), still think that the proliferation of wiki markups place everyone in position where one just can pick a syntax to use almost at random. And for fossil it has been picked already. Thanks Michal ___ 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 future of markdown-in-fossil
On 3 August 2012 15:14, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Aug 3, 2012, at 14:57 , Stephan Beal wrote: That said: in several of my fossil wikis i store Google Code format in the wiki and render it client-side. My only point there is that it _is_ currently possible to integrate any wiki format(s) you want to as long as you can render them client-side, and if you are using multiple formats you need a way of differentiating them (so you know which rendered to use), e.g. via a naming convention or a special markup tag in the first line, or similar. Is it possible to bundle this solution into a single binary like the original Fossil? In current fossil you would have to patch the JavaScript code into the HTML template that is in the fossil code and rebuild fossil. This is obviously problematic because you will have to provide binaries for all platforms you want to support. When user HTML templates are implemented it will be possible to store in the HTML template, presumably as part of configuration that can be replicated along with the repository content. Thanks Michal ___ 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 future of markdown-in-fossil
On Fri, 3 Aug 2012 15:06:45 +0200 Michal Suchanek hramr...@gmail.com wrote: [...] Stackoverflow and all the sites under its umbrella, and all the sites using this engine, use (modified) markdown syntax [1], [2]. So again a somewhat slightly incompatible variation. Correct, but I hardly perceive this as being an issue. [...] I, for one, while not being a special fan of markdown syntax (to me, the best sytnax I ever had to deal with was that used by wiki.tcl.tk), still think that the proliferation of wiki markups place everyone in position where one just can pick a syntax to use almost at random. And for fossil it has been picked already. The idea behind pushing Markdown (or whatever else) engine to Fossil is providing a *rich* set of markup capabilities. The problem with builtin Fossil markup engine is that its too simplistic to be usable. In fact, it's usable for one-line pages, but as soon as you want to roll something a bit more complicated (itemized/numerated lists being the first feature I need) you bump to the need of writing HTML, with no support from the UI to do so. I do understand the rationale for this approach; if I were the author of Fossil (I'm incapable for this, but let's pretend I am, for the moment) I'd probably pick the same approach during an early phase of development. Now it seems that quite many users see overly simple markup capabilities of the Fossil's wiki engine to be a problem; a soultion exists and is even integrated. ___ 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 future of markdown-in-fossil
On Fri, 3 Aug 2012 14:02:38 +0200 Natacha Porté nata...@instinctive.eu wrote: [...] As I have said elsewhere, I'm not clever enough to imagine a solution to introduce markdown into fossil's internal wiki. So I don't propose it. I propose the extra embedded doc rendering, and the tools to perform any markdown-to-html conversion. When someone comes up with a way to deal with the internal wiki, they will have such tools. Ikiwiki allows to use several different markup engines for its pages (markdown is builtin, others can be installed in the form of plugins), and it allows the author to pick the markup engine for the page at the time the page is created (see the attached image). The type of markup syntax selected for the page is then codified in the extension of the file which is created by the wiki engine for that page. Supposedly, Fossil's wiki page editor could provide the same pick list the first time a page is created and then persist the chosen markup syntax with the page entry itself in an appropriate table. Is that possible? [...] attachment: ikiwiki-page-editor-syntax-pick-dropdown-list.png___ 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 future of markdown-in-fossil
On 2012-08-03 11:53, Michal Suchanek wrote:
On 3 August 2012 11:23, Remigiusz Modrzejewski l...@maxnet.org.pl
wrote:
On Jul 30, 2012, at 19:43 , Gautier DI FOLCO wrote:
2012/7/30 Bill Burdick bill.burd...@gmail.com
I'd like to see it included, as well!
I'd like it too, it will be easier for beginnes (like me!).
+1
Why markdown and not one of the dozens of other wiki syntaxes?
I don't find wiki syntaxes really easy. Maybe a bit easier to type
than HTML but definitely not easy to read or remember, especially
since there are dozens of slightly (and not so slightly) different
variants.
Note there are JavaScript hacks for interpreting random wiki syntax
so
you can have markdown interpreted without any direct support in
fossil.
Thanks
Michal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Nice things are starting to heat up :-) let me throw some oil on the
fire.
I don't find any wiki syntaxes to be what you need. At one point they
all fall short.
However writing html isn't my favourite therapy and there a wiki syntax
can be handy.
I'm quite pleased as a wiki language takes 80% of my hands.
The advantage of this particular implementation is that it is C coded
and that the license is compatible with fossil.
And with Nataschsa's extension it becomes workable.
I rather write
\
figure 5
{on a side note I would prefer this
\
because a pure markdown implementation would still get the
link right only the description
is strange. and in The above example a pure markdown will
not get the link right}
then
centertable border=1 cellpadding=10 hspace=10 vspace=10
trtd align=center
img src=branch05.gif width=485 height=177br
Figure 5
/td/tr/table/center
But this could have been written like
table class=table_centered_imagetrtdimg src=branch05.gif
width=485 eight=177brFigure
5/td/tr/table
or maybe like
div class=centered_image img src=branch05.gif width=485
eight=177brFigure 5/div
in general tag languages can get rather verbose!
But still the Markdown version ( and most wiki's), IMHO, is, slightly,
better readable.
Your suggestion to use javascript to display wiki markup is possible.
and interesting
what do we do with the javascript library?
it is not part of your project which will deliver fantastic software
without markdown.
So is it part of fossil?
If you clone the repo than you want the same kind of services as the
original.
How can that be done in a consistent manor?
It gives me a headache to think that out.
Of course you don't want MarkDown but you want MarkUp. Stephen will say
that you have to resort to JSON.
maybe that is the right answer.
On his site http://daringfireball.net/projects/markdown/ the markdown
inventor says
The idea is that a Markdown-formatted document should be
publishable as-is, as plain text,
without looking like it’s been marked up with tags or formatting
instructions.
I think it looks awkward any way.
--
Rene
___
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 future of markdown-in-fossil
On Fri, Aug 3, 2012 at 3:31 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: I do understand the rationale for this approach; if I were the author of Fossil (I'm incapable for this, but let's pretend I am, for the moment) I'd probably pick the same approach during an early phase of development. Now it seems that quite many users see overly simple markup capabilities of the Fossil's wiki engine to be a problem; a soultion exists and is even integrated. Another consideration here is that the wiki has kind of fallen out of use, with the embedded docs system generally being preferred. While i admit that i pay a good deal of attention to fossil's wiki API (i've added several of the wiki subcommands and the wiki API was amongst the first of the JSON APIs added), i will admit that embedded docs are generally a better solution. But the wiki is just too convenient (which is the only reason anyone really uses a wiki, anyway). Once i get embedded docs support in the JSON API, i probably won't touch the wiki API again. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
On Fri, Aug 3, 2012 at 3:37 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: Supposedly, Fossil's wiki page editor could provide the same pick list the first time a page is created and then persist the chosen markup syntax with the page entry itself in an appropriate table. Is that possible? (Restricting myself to client-side for the moment...) In fact... the direct forefather of fossil's JSON wiki API demonstrates doing exactly this: http://whiki.wanderinghorse.net/?page=whiki These pages show 3 page-specified renderers in action (it uses a name-extension mapper): http://whiki.wanderinghorse.net/?page=fossil2whiki.sh http://whiki.wanderinghorse.net/?page=MarkDownTest http://whiki.wanderinghorse.net/?page=README.txt JSON API derives directly from whiki (which was originally written to replace fossil's wiki for some of my projects, so that code ended up coming full-circle), and i see no reason this cannot be done with fossil's json wiki API as well. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
On Fri, Aug 3, 2012 at 3:47 PM, Stephan Beal sgb...@googlemail.com wrote: These pages show 3 page-specified renderers in action (it uses a name-extension mapper): That's a lie - each page has a client-specified mime-type string. Click on the editor button on these pages to see that. http://whiki.wanderinghorse.net/?page=fossil2whiki.sh http://whiki.wanderinghorse.net/?page=MarkDownTest http://whiki.wanderinghorse.net/?page=README.txt -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
On Fri, 3 Aug 2012 15:42:05 +0200 Stephan Beal sgb...@googlemail.com wrote: I do understand the rationale for this approach; if I were the author of Fossil (I'm incapable for this, but let's pretend I am, for the moment) I'd probably pick the same approach during an early phase of development. Now it seems that quite many users see overly simple markup capabilities of the Fossil's wiki engine to be a problem; a soultion exists and is even integrated. Another consideration here is that the wiki has kind of fallen out of use, with the embedded docs system generally being preferred. While i admit that i pay a good deal of attention to fossil's wiki API (i've added several of the wiki subcommands and the wiki API was amongst the first of the JSON APIs added), i will admit that embedded docs are generally a better solution. But the wiki is just too convenient (which is the only reason anyone really uses a wiki, anyway). Once i get embedded docs support in the JSON API, i probably won't touch the wiki API again. My personal use case for Fossil's intergated wiki is a structured place to perform brain dumps: that is, I have a problem to solve (and I'm writing code which is to solve it, hosting it using Fossil), and start to write down my observations on how to attack different parts of it, findings on the nature of the data I had to process etc. This fits the wiki paradigm rather well and does not really fit to the domain of the built-in documentation. Unfortunately, in my case I did have the need to use nested lists, convenient ways to insert multiline verbatim bits of text, and I'd love to have some (basic) support for tables (what ikiwiki has [1] would be just enough). Uploading images and inserting wiki links to them would also be a win for me (again, ikiwiki provides for this; this is called attachments in its lingo [2]). This would probably be an overkill for a markup engine built into Fossil, but I found myself wanting this feature more than once. Yeah, every time I think about this I do understand I could just create a page in my intranet ikiwiki instance an link to it from my Fossil's project's wiki page, but this kind of questions the whole point of having a built-in wiki engine. ;-) P.S. I'm constantly referring to ikiwiki because it stores all its content in a [D]VCS (Git in my particular case), and so does Fossil with its wiki engine. 1. http://ikiwiki.info/ikiwiki/directive/table/ 2. http://ikiwiki.info/plugins/attachment/ ___ 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 future of markdown-in-fossil
Michal Suchanek escribió: Note there are JavaScript hacks for interpreting random wiki syntax so you can have markdown interpreted without any direct support in fossil. Note there are good wiki engines out there, so no need for one in Fossil too. But once we set the scope to include something, please don't keep it half-hearted... And it has been said that markdown is out of the scope of Fossil. I am not to decide that but I have to agree. Once you let in markdown people used to some other wiki syntax would argue they have needlessly hard time and there would be no end to the stream of requests to include yet another. Wholeheartedly agreed. Let's stop with the wiki markup discussions and keep the list DSCM related... PLEASE. -- o-= Marcelo =-o ___ 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 future of markdown-in-fossil
Remigiusz Modrzejewski decía, en el mensaje Re: [fossil-users] The future of markdown-in-fossil del Viernes, 03 de Agosto de 2012 07:26:27: I've read the we'll have requests for all the markups in the world argument many times. I can't remember anyone actually coming and asking for *anything* else than markdown. I was going to wait until the whole Markup brouhaha was ended, but I for one would like support for reStructuredText :) -- o-= Marcelo =-o ___ 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 future of markdown-in-fossil
On Mon, Jul 30, 2012 at 10:41 AM, Natacha Porté nata...@instinctive.euwrote: Currently the code is in a new branch off a clone of the official fossil repository, available at http://fossil.instinctive.eu/fossil-scm/timeline?r=markdown Can you please update your fossil binary so that: /vdiff?branch=markdown will work? That makes looking at branch-wide diffs MUCH simpler :). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
Hello, on Friday 03 August 2012 at 19:11, Stephan Beal wrote: On Mon, Jul 30, 2012 at 10:41 AM, Natacha Porté nata...@instinctive.euwrote: Currently the code is in a new branch off a clone of the official fossil repository, available at http://fossil.instinctive.eu/fossil-scm/timeline?r=markdown Can you please update your fossil binary so that: /vdiff?branch=markdown will work? That makes looking at branch-wide diffs MUCH simpler :). Done (actually since there is no new packaged version, I justed configured it to use trunk+markdown binary instead of the stable system binary). Moreover, I have just subscribed to fossil-dev, in case you wish to move part of the discussion there. Natacha Porté pgpJX7f9AkNNL.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] The future of markdown-in-fossil
n Tue, Jul 31, 2012 at 12:58 AM, Bill Burdick bill.burd...@gmail.comwrote: Looks like it's using wiki pages, to me, just not stored in the Fossil wiki -- at least, that what the Editor button tells me... :) They are actually stored in fossil, but not in the same repo as the sources. i don't want fossil mis-rendering the Google Code pages, so i hide those in their own repo and only expose them via my ui. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
On Tue, Jul 31, 2012 at 1:00 AM, Bill Burdick bill.burd...@gmail.comwrote: Very slick front-end, BTW! i appreciate the compliment, but we all know i have no gift for visual design ;). i had a designer at work help me out with the css, so it doesn't look half as bad as it originally did, but it could certainly be made prettier by someone who has a knack for that sort of thing. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
Hello, I don't want to look impatient, and I personally hate to be constantly reminded about something that hasn't actually left my mind, so I'm a bit reluctant to send e-mails like this one. All my apologies if I'm doing it wrong. So my point is only to remind you all that I'm still committed to make the fossil-in-markdown thing going forward, and I'm eagerly waiting any instructions on what to do about it next. Currently the code is in a new branch off a clone of the official fossil repository, available at http://fossil.instinctive.eu/fossil-scm/timeline?r=markdown There is also a live demo (dedicated repository served using a fossil compiled off this branch) at http://fossil.instinctive.eu/markdown-examples/doc/tip/README.mkd What is done: + complete and seamless integration of the markdown engine into fossil (e.g. using fossil blobs as dynamic buffers), + support of markdown embedded documentation (.markdown and .mkd extensions), using current fossil style, + regular merge of latest changes from trunk. What remains to do: + review my code to ensure it meets fossil level of quality, + format it using fossil code style if needed, + any other code change that comes up during the review. I'm still willing to perform any maintenance needed on the markdown library code and/or the glue between it and fossil, for as long as I can. I would also gladly handle any knowledge-transfer needed to prevent myself from being a single point of failure in the maintenance of that code. Thanks for your interest, Natacha Porté pgpTIxNrHgoYg.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] The future of markdown-in-fossil
On Mon, Jul 30, 2012 at 10:41 AM, Natacha Porté nata...@instinctive.euwrote: What remains to do: + review my code to ensure it meets fossil level of quality, + format it using fossil code style if needed, + any other code change that comes up during the review. i will be happy to offer my 0.0163 Euros, but i won't be able to do so until later in the week. Richard is, from what i understand, swamped for the foreseeable future. Of course, anyone else is encouraged to help :). While i don't personally use MD i'd like to see it added if only because people keep asking about it ;). Maybe then some of the religious wars can end ;). i will post back once i have looked over it. Would you prefer that i send comments regarding it to the list or to you directly? Thanks for your interest, And thank you for your contribution and persistence. To be clear: the final decision about what goes in to the trunk belongs to Richard and Richard alone. The other contributors, such as a myself, are here to assist, but the final decision rests with him. For what i'd worth, i'd like to see it included (but would like to look at the code first ;). Happy Hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
I'd like to see it included, as well! On Mon, Jul 30, 2012 at 11:53 AM, Stephan Beal sgb...@googlemail.comwrote: On Mon, Jul 30, 2012 at 10:41 AM, Natacha Porté nata...@instinctive.euwrote: What remains to do: + review my code to ensure it meets fossil level of quality, + format it using fossil code style if needed, + any other code change that comes up during the review. i will be happy to offer my 0.0163 Euros, but i won't be able to do so until later in the week. Richard is, from what i understand, swamped for the foreseeable future. Of course, anyone else is encouraged to help :). While i don't personally use MD i'd like to see it added if only because people keep asking about it ;). Maybe then some of the religious wars can end ;). i will post back once i have looked over it. Would you prefer that i send comments regarding it to the list or to you directly? Thanks for your interest, And thank you for your contribution and persistence. To be clear: the final decision about what goes in to the trunk belongs to Richard and Richard alone. The other contributors, such as a myself, are here to assist, but the final decision rests with him. For what i'd worth, i'd like to see it included (but would like to look at the code first ;). Happy Hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
2012/7/30 Bill Burdick bill.burd...@gmail.com I'd like to see it included, as well! I'd like it too, it will be easier for beginnes (like me!). ___ 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 future of markdown-in-fossil
On 2012-07-30 10:41, Natacha Porté wrote: Hello, I don't want to look impatient, and I personally hate to be constantly reminded about something that hasn't actually left my mind, so I'm a bit reluctant to send e-mails like this one. All my apologies if I'm doing it wrong. So my point is only to remind you all that I'm still committed to make the fossil-in-markdown thing going forward, and I'm eagerly waiting any instructions on what to do about it next. Currently the code is in a new branch off a clone of the official fossil repository, available at http://fossil.instinctive.eu/fossil-scm/timeline?r=markdown There is also a live demo (dedicated repository served using a fossil compiled off this branch) at http://fossil.instinctive.eu/markdown-examples/doc/tip/README.mkd What is done: + complete and seamless integration of the markdown engine into fossil (e.g. using fossil blobs as dynamic buffers), + support of markdown embedded documentation (.markdown and .mkd extensions), using current fossil style, + regular merge of latest changes from trunk. What remains to do: + review my code to ensure it meets fossil level of quality, + format it using fossil code style if needed, + any other code change that comes up during the review. I'm still willing to perform any maintenance needed on the markdown library code and/or the glue between it and fossil, for as long as I can. I would also gladly handle any knowledge-transfer needed to prevent myself from being a single point of failure in the maintenance of that code. Thanks for your interest, Natacha Porté Are we going to move all the wikipages to markdown? I converted the attached file to markdown it wasn't to difficult with bit of sed, awk and pandoc. What do you see as an advantage of markdown compared to the current wiki syntax? -- Reneadd --- The often used `add` command is how you tell **fossil** to include a (usually new) file in the repository. **fossil** is designed to manage artifacts whose role is being source for something, most probably software program code or other text. One can imagine all kinds of ways to let fossil know just what constitutes a source; the simplest and most direct way it *actually* finds out is when you give it the ` fossil add path ` command. It's reasonable to think of the [`import`](./cmd_import.wiki) and [`clone`](./cmd_clone.wiki) commands as very high-powered versions of the `add` command that are combined with system level file movement and networking functions. Not particularly accurate, but reasonable. Typing `fossil add myfile` causes fossil to put *myfile* into the repository at the next `commit`provided you issue it from within the source tree, of course. By contrast, `fossil add mydirectory` will add ***all*** of the files in *mydirectory*, and all of its sub-directories. In other words, adding a directory will recursively add all of the directory's file system descendants to the repository. This was an oft-requested feature, recently implemented. It is very flexible. Only when you add a directory do you get the recursive behavior. If you are globbing a subset of files, you won't get the recursion. Realize that the repository is not changed by the `add` command, but by the `commit` command. `add` *myfile* tells **fossil** to mark *myfile* as part of the repository. Only commands which actually manipulate the content of the repository can physically put source artifacts into (or remove them from) the repository. Just to keep things symmetric, there are also commands that can manipulate the repository without affecting the checked-out sources (see [fossil pull](./cmd_pull.wiki), for instance.) It's worthwhile reiterating that **fossil** is storing the content of source artifacts and the names of the artifacts in their native habitat, a sequence of temporal slices (aka versions) of the state of the whole system, and a set of unique identifiers. When you add a file to a repository, the *path* to the file is a part of the *name* of the file. There is a mis-match between the file system's idea of a directory (a file containing pointers to files) and fossil's idea (a substring of the name of the artifact.) The names of the artifacts specify their relative locations because of the way the file system interprets them. If you don't keep this in mind, you may fool yourself into thinking **fossil** somehow stores directories. It doesn't, and believing it does will eventually confuse you. See also: [fossil rm](./cmd_rm.wiki), [fossil import](./cmd_import.wiki), [fossil clone](./cmd_clone.wiki), [fossil commit](./cmd_commit.wiki), [fossil pull](./cmd_pull.wiki), [fossil setting](./cmd_settings.wiki) (async), [Reference](./reference.wiki) ___ 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 future of markdown-in-fossil
On Mon, Jul 30, 2012 at 9:29 PM, Rene renew...@xs4all.nl wrote: Are we going to move all the wikipages to markdown? The main repo doesn't use wiki pages any more - the embedded docs feature is preferred because it's versioned along with the rest of the site. Wikis _are_ versioned but there is no UI for traversing specific versions or referencing them from [wikiLinks], etc., so they don't tend to get used much. i use them a bit in my own sites, but half of those are running a custom Google Code syntax renderer on top of a fossil back-end, using the JSON API to transport it, e.g.: http://fossil.wanderinghorse.net/wikis/cson/ that's a fossil back-end with a completely custom front-end which reveals only the wiki to the user. I converted the attached file to markdown it wasn't to difficult with bit of sed, awk and pandoc. What do you see as an advantage of markdown compared to the current wiki syntax? Here's a similar script for fossil-to-GoogleCode format can probably be re-used a bit for markdown: http://whiki.wanderinghorse.net/?page=fossil2whiki.sh Happy Hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
Looks like it's using wiki pages, to me, just not stored in the Fossil wiki -- at least, that what the Editor button tells me... :) On Mon, Jul 30, 2012 at 5:52 PM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 30, 2012 at 9:29 PM, Rene renew...@xs4all.nl wrote: Are we going to move all the wikipages to markdown? The main repo doesn't use wiki pages any more - the embedded docs feature is preferred because it's versioned along with the rest of the site. Wikis _are_ versioned but there is no UI for traversing specific versions or referencing them from [wikiLinks], etc., so they don't tend to get used much. i use them a bit in my own sites, but half of those are running a custom Google Code syntax renderer on top of a fossil back-end, using the JSON API to transport it, e.g.: http://fossil.wanderinghorse.net/wikis/cson/ that's a fossil back-end with a completely custom front-end which reveals only the wiki to the user. I converted the attached file to markdown it wasn't to difficult with bit of sed, awk and pandoc. What do you see as an advantage of markdown compared to the current wiki syntax? Here's a similar script for fossil-to-GoogleCode format can probably be re-used a bit for markdown: http://whiki.wanderinghorse.net/?page=fossil2whiki.sh Happy Hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 future of markdown-in-fossil
Very slick front-end, BTW! On Mon, Jul 30, 2012 at 5:58 PM, Bill Burdick bill.burd...@gmail.comwrote: Looks like it's using wiki pages, to me, just not stored in the Fossil wiki -- at least, that what the Editor button tells me... :) On Mon, Jul 30, 2012 at 5:52 PM, Stephan Beal sgb...@googlemail.comwrote: On Mon, Jul 30, 2012 at 9:29 PM, Rene renew...@xs4all.nl wrote: Are we going to move all the wikipages to markdown? The main repo doesn't use wiki pages any more - the embedded docs feature is preferred because it's versioned along with the rest of the site. Wikis _are_ versioned but there is no UI for traversing specific versions or referencing them from [wikiLinks], etc., so they don't tend to get used much. i use them a bit in my own sites, but half of those are running a custom Google Code syntax renderer on top of a fossil back-end, using the JSON API to transport it, e.g.: http://fossil.wanderinghorse.net/wikis/cson/ that's a fossil back-end with a completely custom front-end which reveals only the wiki to the user. I converted the attached file to markdown it wasn't to difficult with bit of sed, awk and pandoc. What do you see as an advantage of markdown compared to the current wiki syntax? Here's a similar script for fossil-to-GoogleCode format can probably be re-used a bit for markdown: http://whiki.wanderinghorse.net/?page=fossil2whiki.sh Happy Hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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
