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
[fossil-users] usability of in-project documentation
hello, while the wiki has its entry in the fossil menu and is easy to find the in-project documentation is not so obvious. As a fossil user I have to read the manual to find the docs at all so I would know. The manual is even quite well explained and almost exhaustive. However, if I were to direct people to the in-project docs who are not seasoned fossil users themselves I can envision quite a few problems. Firstly, fossil has undocumented index file support, and the index file name is hardcoded in the fossil source. Interestingly, this index file is index.html (only). Having checked index.wiki or README or readme.txt into the repository is no use. You will have to use an index.html with redirect to have one of those files as index. Second, the doc/ hierarchy behaves very odd compared to what users would expect after visiting sites served by other we servers. The url http://www.fossil-scm.org/fossil/doc contains: No such document: index.wiki This is very misleading. I have no idea where this comes from as 1) there is no possibility that any files reside on this URL 2) index.wiki is not index file of anything I guess if this page was to contain useful content it could redirect to tip or other configurable branch or just list branches (and include ckout in the list when an open repository is served). The url http://www.fossil-scm.org/fossil/doc/trunk contains: No such document: index.html This is more to the point since it complains about non-existence of the undocumented index file. However, if the file did exist and was served through this url it would necessarily have broken links. Or the links would be broken when served through http://www.fossil-scm.org/fossil/doc/trunk/ or http://www.fossil-scm.org/fossil/doc/trunk/index.html because the latter urls are down one directory in the url hierarchy. Redirection to single URL is required for such file to work. The url http://www.fossil-scm.org/fossil/doc/www again complains about the missing index file. In the current fossil release it would complain that www does not exist, and only allow http://www.fossil-scm.org/fossil/doc/www/ I also notice that while the CSS is customizable the HTML templates are not. While this is not much of a problem for many projects in some cases you would want to reorganize the page layout and/or add additional elements. At the very least adding some more divs off which to hang the style rules would be useful. eg. I was considering to add a background to the page header but noticed that by default the body has 1ex margin which prevents the header background from reaching the sides of the page. Removing this margin starts a cascade of changes required to return to remotely sane formatting while stylistic-only header and content div which implements the margin and possibly background in place of the body element would work wonderfully. Is there any chance that the in-repo doc serving is polished at least to the point that it's usable by unsuspecting people just browsing the web without realizing this is in fact a fossil repository. As it is the fossil served pages need to be used very carefully because they are quite fragile compared to what you would expect from, say, static directory structure served off apache. I am not opposed to writing patches, and all these issues are quite trivial but I am also aware that some patches are rotting in the fossil tickets for years so I guess patches are not what gives you fixed fossil. I can apply them locally but it does not help if I want other people to be able to mirror my repo or use chiselapp, or whatever. And I need to rebuild for every architecture myself since whatever official packages exist will never get my local patches. 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 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] usability of in-project documentation
On Fri, Aug 3, 2012 at 11:48 AM, Michal Suchanek hramr...@gmail.com wrote: huge snip I also notice that while the CSS is customizable the HTML templates are not. While this is not much of a problem for many projects in some cases you would want to reorganize the page layout and/or add additional elements. At the very least adding some more divs off which Hi Michal, FWIW: the up-coming/in-development custom pages/commands support will allow one to do this more easily. Once that is in place, it is very possible that we will (at least be able to) replace the current header/footer mechanism on top of the templates bits which the custom pages need. I am not opposed to writing patches, and all these issues are quite trivial but I am also aware that some patches are rotting in the fossil tickets for years so I guess patches are not what gives you fixed fossil. i suspect the main problem there is that fossil lacks triggers/email notifications (for portability reasons), and if the ticket doesn't get noticed in the first page of the timeline view (the first 20 entries) then it probably goes unnoticed more often than not. I can apply them locally but it does not help if I want other people to be able to mirror my repo or use chiselapp, or whatever. And I need to rebuild for every architecture myself since whatever official packages exist will never get my local patches. If you have picked out patches from tickets which you know to work, i would be willing to get them integrated provided that: a) it makes sense to do so. Some feature requests don't fit well into fossil's world view. b) The patches are still current vis-a-vis the trunk. c) There are no objections from Richard or other contributors. This decision ultimately lies with Richard, by the way, not myself. Have you got the list of ticket numbers (or the patches)? This list doesn't accept attachments (IIRC), but if you have the patches, please send them to me off-list and i will get to that this weekend. -- - 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 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] usability of in-project documentation
On 3 August 2012 14:45, Stephan Beal sgb...@googlemail.com wrote: On Fri, Aug 3, 2012 at 11:48 AM, Michal Suchanek I am not opposed to writing patches, and all these issues are quite trivial but I am also aware that some patches are rotting in the fossil tickets for years so I guess patches are not what gives you fixed fossil. i suspect the main problem there is that fossil lacks triggers/email notifications (for portability reasons), and if the ticket doesn't get noticed in the first page of the timeline view (the first 20 entries) then it probably goes unnoticed more often than not. Another problem is that fossil needs a contributor agreement so random patches attached to the tickets are not going to make it into 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 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] templates (WAS: Re: The future of markdown-in-fossil(
On 3 August 2012 15:39, Stephan Beal sgb...@googlemail.com wrote: On Fri, Aug 3, 2012 at 3:22 PM, Michal Suchanek hramr...@gmail.com wrote: 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. Correct. The initial implementation might not be directly syncable, but that is the long-term plan. If we decide to use in-filesystem templates (like the embedded docs, basically) then they would sync automatically. But we also need a mechanism which prohibits the import of malicious templates via syncronization, so this detail has to be considered carefully (input is of course welcomed). And how do you prevent malicious code import through synchronization? This is the exact same thing. Either you don't import or don't use what you import or you are vulnerable to what you import. Thanks Michal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] MIME types in Fossil's document server
I'm having a weird problem serving up files in my /doc/tip/*. Some of the files I access through that tree are source files. If the source files are foo.m (Mercury source), fossil serves them up as MIME type text/html and it gets displayed nicely in my browser (Firefox 14). If, however, the source files are foo.sno (SNOBOL4 source), fossil serves them up as… well, I'm not absolutely positive. Firefox reports them as sno File and won't give me an option to display them, only to download them and/or to associate them with an application. Why is Fossil reporting things so differently for .sno files over .m files and how do I get it to stop? -- Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot. --Sergey Brin, demonstrating the emptiness of the don't be evil mantra. ___ 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] templates (WAS: Re: The future of markdown-in-fossil(
On Fri, Aug 3, 2012 at 3:49 PM, Michal Suchanek hramr...@gmail.com wrote: And how do you prevent malicious code import through synchronization? The same way Windows does, of course: This app comes from god-only-knows where. Do you want to run it? ;) i have absolutely no idea, to be honest. This is the exact same thing. Either you don't import or don't use what you import or you are vulnerable to what you import. The difference with custom commands, compared to what is currently syncable, is that they will have a lot more power via access to stuff which was not accessible before. e.g. a query API has been added to the scripting language (th1). One very interesting (under consideration) feature of custom commands/pages is that we could _potentially_ offer an option to direct built-in commands to a custom command. If such things are synced, then i might get your version of fossil status instead of mine, and that would upset me. The custom commands API currently offers nothing which will allow one to change a repo's state and there are NO plans to add such APIs, for repo integrity reasons. Even so, with greater power comes bigger cans of worms, so any synchronization must be carefully considered. Initial templates/commands support _might_ live in a new table of its own (this is still undecided) which will initially not be syncable but would eventually be made so, _probably_ via an extension of the config command (or something equivalent). They might live in the artifacts table (where they could be versioned and synced as normal artifacts), and whether or not to version custom pages/commands is a decision which has not yet been made (as always: opinions on the matter are welcomed). It might be interesting, and wouldn't be much work, to provide several methods for storing custom commands: config table, artifacts, and/or local files. e.g. for prototyping this support i use local files, and once i'm (eventually) satisfied with the overall model i'll figure out (hopefully with the help of the community) where best to store such things. -- - 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] MIME types in Fossil's document server
On 3 August 2012 15:54, Michael Richter ttmrich...@gmail.com wrote: I'm having a weird problem serving up files in my /doc/tip/*. Some of the files I access through that tree are source files. If the source files are foo.m (Mercury source), fossil serves them up as MIME type text/html and it gets displayed nicely in my browser (Firefox 14). If, however, the source files are foo.sno (SNOBOL4 source), fossil serves them up as… well, I'm not absolutely positive. Firefox reports them as sno File and won't give me an option to display them, only to download them and/or to associate them with an application. Why is Fossil reporting things so differently for .sno files over .m files Because it does not know about .sno files. Even reporting .m as text/html is bogus, obviously. The built-in table shows it should be assigned text/plain, however. and how do I get it to stop? Patch fossil. AFAICT this is not configurable. Alternatively, install a firefox extension that allows viewing files in firefox. Unlike some other browsers Firefox is quite asinine wrt mime types and refuses to show anything that is not of one of the few viewable types it has hardcoded somewhere. HTH 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] MIME types in Fossil's document server
On Fri, Aug 3, 2012 at 4:09 PM, Michal Suchanek hramr...@gmail.com wrote: Because it does not know about .sno files. Even reporting .m as text/html is bogus, obviously. The built-in table shows it should be assigned text/plain, however. At one point we tossed around the idea of adding a client-extensible mimetype table, but nobody has ever gotten around to adding it. (Hint: i would like to see it implemented via the configure system, such that it syncs via config push/pull.) If someone will add this, i will extend the build-system to automatically create some default contents from /etc/mime.types if it's available. Patch fossil. AFAICT this is not configurable. Correct. -- - 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] templates (WAS: Re: The future of markdown-in-fossil(
On 3 August 2012 16:03, Stephan Beal sgb...@googlemail.com wrote: On Fri, Aug 3, 2012 at 3:49 PM, Michal Suchanek hramr...@gmail.com wrote: And how do you prevent malicious code import through synchronization? The same way Windows does, of course: This app comes from god-only-knows where. Do you want to run it? ;) i have absolutely no idea, to be honest. Well, you don't because your system has no security. No system in wide use today has. This is the exact same thing. Either you don't import or don't use what you import or you are vulnerable to what you import. The difference with custom commands, compared to what is currently syncable, is that they will have a lot more power via access to stuff which was not accessible before. e.g. a query API has been added to the scripting language (th1). One very interesting (under consideration) feature of custom commands/pages is that we could _potentially_ offer an option to direct built-in commands to a custom command. If such things are synced, then i might get your version of fossil status instead of mine, and that would upset me. The custom commands API currently offers nothing which will allow one to change a repo's state and there are NO plans to add such APIs, for repo integrity reasons. Even so, with greater power comes bigger cans of worms, so any synchronization must be carefully considered. I don't think that doing this is desirable. fossil status should be fossil status. You might want to write a separate script to replace it. It might be useful to be able to make fossil mystatus, too. The web interface is optional and it is fine to be able to change it with synchronization. Of course, if you run fossil serve and browse to the web interface which is synchronized from upstream you are open to browser attacks. But the same applies if you browse HTML documentation included in the project (or PDF documentation with overly clever PDF reader), or run projects build or other scripts, or run the binaries. Initial templates/commands support _might_ live in a new table of its own (this is still undecided) which will initially not be syncable but would eventually be made so, _probably_ via an extension of the config command (or something equivalent). They might live in the artifacts table (where they could be versioned and synced as normal artifacts), and whether or not to version custom pages/commands is a decision which has not yet been made (as always: opinions on the matter are welcomed). It might be interesting, and wouldn't be much work, to provide several methods for storing custom commands: config table, artifacts, and/or local files. e.g. for prototyping this support i use local files, and once i'm (eventually) satisfied with the overall model i'll figure out (hopefully with the help of the community) where best to store such things. Versioning them is probably a good idea. Still if you are editing and testing the pages in the browser it might be good idea to make whatever you save a 'checkout' which is only synced when you 'commit' it. Otherwise you are going to make tons of small meaningless commits as you edit small details of templates and stylesheets. 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] templates (WAS: Re: The future of markdown-in-fossil(
On Fri, Aug 3, 2012 at 4:30 PM, Michal Suchanek hramr...@gmail.com wrote: I don't think that doing this is desirable. fossil status should be fossil status. And i agree entirely, i just posted the idea as a possible extension of the custom commands (since this is an evolutionary process, and custom commands will enable new directions for growth). You might want to write a separate script to replace it. It might be useful to be able to make fossil mystatus, too. On my system it's fst, but custom commands may (depending on the APIs we would need to make scriptable) give users a way to completely customize that, e.g.: fossil my-stat branch: foo Edited: foo.c bar.c Deleted: baz.c ... (That isn't currently possible because we don't (yet?) have th1 bindings needed for those particular ops, but you get the idea.) browser attacks. But the same applies if you browse HTML documentation included in the project (or PDF documentation with overly clever PDF reader), or run projects build or other scripts, or run the binaries. Absolutely agreed. Versioning them is probably a good idea. And that will be done at some point. For prototyping i just use local files because it's non-obtrusive and lets me concentrate on the templating system and the required th1 APIs, rather than with the versioning and whatnot. Still if you are editing and testing the pages in the browser it might be good idea to make whatever you save a 'checkout' which is only synced when you 'commit' it. Otherwise you are going to make tons of small meaningless commits as you edit small details of templates and stylesheets. This could be done using something like the wiki's preview feature, where the client submits wiki content and the server renders it without saving it. On a related note... with the JSON bits it would be really easy to add per-user and/or per-login-session persistent data with JSON's rich data structure complexity and strong data type support. So far there has not been a truly compelling reason to add it (and it potentially adds db maintenance overhead), so it has not been implemented [in fossil - i have implemented it in another tree using the same JSON C library, and porting it would be trivial]. Such a feature could, however, be used to store drafts of wiki pages, templates, custom commands, or whatever custom UIs need to save. Custom commands could even be given access to that data via new TH1 bindings (which might be cool). -- - 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] templates (WAS: Re: The future of markdown-in-fossil(
On 3 August 2012 16:43, Stephan Beal sgb...@googlemail.com wrote: On Fri, Aug 3, 2012 at 4:30 PM, Michal Suchanek hramr...@gmail.com wrote: I don't think that doing this is desirable. fossil status should be fossil status. And i agree entirely, i just posted the idea as a possible extension of the custom commands (since this is an evolutionary process, and custom commands will enable new directions for growth). I guess renaming commands (or replacing or aliasing, ..) could be a local configuration, similar to user accounts used for the web UI, CR/LF conversion, commiter email, and whatnot. Then you can have a custom command synced from upstream and locally alias it to replace one of the standard commands - or not. Still if you are editing and testing the pages in the browser it might be good idea to make whatever you save a 'checkout' which is only synced when you 'commit' it. Otherwise you are going to make tons of small meaningless commits as you edit small details of templates and stylesheets. This could be done using something like the wiki's preview feature, where the client submits wiki content and the server renders it without saving it. This is rather difficult currently. You have to use force-refresh for CSS changes to show in the browser. Could be easily fixed with referencing style-draft-date.css or style-version.css rather than style.css. Or with a proper date and cache control in the header I guess. 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] usability of in-project documentation
On 2012-08-03 11:48, Michal Suchanek wrote: hello, while the wiki has its entry in the fossil menu and is easy to find the in-project documentation is not so obvious. As a fossil user I have to read the manual to find the docs at all so I would know. The manual is even quite well explained and almost exhaustive. However, if I were to direct people to the in-project docs who are not seasoned fossil users themselves I can envision quite a few problems. Fossil has evolved this way. However you can do the right thing on your project. so many ways of generating documentation docbook, lyx, asciidoc, html. wiki. and the generated html can be feed into fossil. Firstly, fossil has undocumented index file support, and the index file name is hardcoded in the fossil source. Interestingly, this index file is index.html (only). Having checked index.wiki or README or readme.txt into the repository is no use. You will have to use an index.html with redirect to have one of those files as index. I'm not sure I follow you. again fossil has evolved this way. You have a wonderful opportunity to take fossil system and build your documentation. Once you compile fossil and do a fossil init documentbetter.fossil followed by a fossil ui documentbetter.fossil, Admin Coniguration you can set the the first page to anything you want. including index.html fossil displays on that page Enter the pathname of the page to display when the Home menu option is selected and when no pathname is specified in the URL. For example, if you visit the url: http://localhost:8080 And you have specified an index page of /home the above will automatically redirect to: http://localhost:8080/home The default /home page displays a Wiki page with the same name as the Project Name specified above. Some sites prefer to redirect to a documentation page (ex: /doc/tip/index.wiki) or to /timeline. Note: To avoid a redirect loop or other problems, this entry must begin with / and it must specify a valid page. For example, /home will work but home will not, since it omits the leading /. Second, the doc/ hierarchy behaves very odd compared to what users would expect after visiting sites served by other we servers. The url http://www.fossil-scm.org/fossil/doc contains: No such document: index.wiki This is very misleading. I have no idea where this comes from as 1) there is no possibility that any files reside on this URL 2) index.wiki is not index file of anything I guess if this page was to contain useful content it could redirect to tip or other configurable branch or just list branches (and include ckout in the list when an open repository is served). The url http://www.fossil-scm.org/fossil/doc/trunk contains: No such document: index.html This is more to the point since it complains about non-existence of the undocumented index file. However, if the file did exist and was served through this url it would necessarily have broken links. Or the links would be broken when served through http://www.fossil-scm.org/fossil/doc/trunk/ or http://www.fossil-scm.org/fossil/doc/trunk/index.html because the latter urls are down one directory in the url hierarchy. Redirection to single URL is required for such file to work. The url http://www.fossil-scm.org/fossil/doc/www again complains about the missing index file. In the current fossil release it would complain that www does not exist, and only allow http://www.fossil-scm.org/fossil/doc/www/ It is called doc. after documentation not after documentroot. and there cannot be anything directly under it. because you can only get documentation from a version. So doc must always be followed by a version. and then your are at the top of your repo. But it won't let you browse thru those files. You need to target one Your right it is inconsistent. Richard and many of us are a bit blind sided from living with fossil. Refreshing that someone takes the time and point that out. It seems like a simple project to rectify the inconsistent naming convention. (hint hint). I know of an other one. -R I would propose that every command where you have to mention a repo it is prefixed by option -R I also notice that while the CSS is customizable the HTML templates are not. While this is not much of a problem for many projects in some cases you would want to reorganize the page layout and/or add additional elements. At the very least adding some more divs off which to hang the style rules would be useful. eg. I was considering to add a background to the page header but noticed that by default the body has 1ex margin which prevents the header background from reaching the sides of the page. Removing this margin starts a cascade of changes Yeah it ain't called cascading style sheet for nothing :-) But the header and the footer are part of the saving. The body is out of reach. because it has be generated from de data required to return to remotely sane formatting while
Re: [fossil-users] usability of in-project documentation
On Fri, Aug 3, 2012 at 6:06 PM, Rene renew...@xs4all.nl wrote: I'm not sure I follow you. again fossil has evolved this way. You have a wonderful opportunity to take fossil system and build ...you can set the the first page to anything you want. including index.html He was referring to fossil's (possibly undocumented) feature that if a /doc dir has a file named index.html then it is served as-is, without any of the normal bling wrapped around it. i only recently learned about it. -- - 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] Making a private branch public?
Hi,
I have a private branch in my Tcl repository, and I wantto turn it into
a public branch that I can push to other repos (without pushing all my
private branches).
I've tried cancelling the 'private' tag (fossil tag cancel --raw) on the
first checkin of the branch, and on the latest, and on every checkin;
nothing seems to cancel the tag ('fossil tag list --raw' still finds it
although the UI shows draw the tag with overstrike). I'm using Fossil 1.22.
I have successfully (so far as I can tell) turned a public branch
private by adding a propagating raw 'private' tag to the first checkin.
I've tried making a branch off my private leaf, but it is marked as
private (even if I don't specify --private).
I've tried branching from the same ancestor as my private branch, and
merging across commits one at a time to recreate the private branch as a
public one, but I get merge conflicts.
Any suggestions?
Regards,
Trevor
___
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] usability of in-project documentation
On 2012-08-03 18:15, Stephan Beal wrote: On Fri, Aug 3, 2012 at 6:06 PM, Rene renew...@xs4all.nl [1] wrote: I'm not sure I follow you. again fossil has evolved this way. You have a wonderful opportunity to take fossil system and build ...you can set the the first page to anything you want. including index.html He was referring to fossil's (possibly undocumented) feature that if a /doc dir has a file named index.html then it is served as-is, without any of the normal bling wrapped around it. i only recently learned about it. That is not only for a directory called /doc. If I make a directory hans i get also No such document: hans/index.html However as you call the doc page it has 2 forms ** WEBPAGE: doc ** URL: /doc?name=BASELINE/PATH ** URL: /doc/BASELINE/PATH ** since name is nonexisting and path also the default is used tip/index.wiki and then you get No such document: index.wiki If you do have a path /doc/trunk/hans/ I am without words by the fact that is does come back with No such document: hans/index.html while the code says: doc_not_found: /* Jump here when unable to locate the document */ db_end_transaction(0); style_header(Document Not Found); @ pNo such document: %h(PD(name,tip/index.wiki))/p Which probably means that it is not coming there! ;-) -- - stephan beal http://wanderinghorse.net/home/stephan/ [2] http://gplus.to/sgbeal [3] Links: -- [1] mailto:renew...@xs4all.nl [2] http://wanderinghorse.net/home/stephan/ [3] http://gplus.to/sgbeal -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
