Re: [fossil-users] Markdown wiki relative links
Sure, a name like /wiki/a/b could be interpreted as /wiki?name=a/b, but it would still break relative paths. It's not enough for Fossil to understand that the / in a/b isn't a path separator; the browser would need to understand that as well. Linking to (c) would either go to /wiki/a/c or /c, but not /wiki/c. On Thu, Jul 5, 2018, 02:30 Dominique Devienne wrote: > On Wed, Jul 4, 2018 at 11:37 PM Stephan Beal > wrote: > >> i don't _think_ that you can use %2f in a path component and have it >> apply different semantics than a slash. How would software know to >> differentiate between the two? That would be similar to expecting a local >> file name of a\/b to work. (If it did work, it would cause no end of >> confusion.) >> > > Sure. The slash(es) would be part of the URL. > But it's the job of the "URL router" to figure it out. > > There's likely a known prefix for wiki pages, so the URL's subpart after > that prefix > can be interpreted as a "name", as is. > > It's definitely not "usual" to route a URL that way, but it certainly > possible IMHO. --DD > ___ > 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] Markdown wiki relative links
On Wed, Jul 4, 2018 at 11:37 PM Stephan Beal wrote: > i don't _think_ that you can use %2f in a path component and have it apply > different semantics than a slash. How would software know to differentiate > between the two? That would be similar to expecting a local file name of > a\/b to work. (If it did work, it would cause no end of confusion.) > Sure. The slash(es) would be part of the URL. But it's the job of the "URL router" to figure it out. There's likely a known prefix for wiki pages, so the URL's subpart after that prefix can be interpreted as a "name", as is. It's definitely not "usual" to route a URL that way, but it certainly possible IMHO. --DD ___ 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] Markdown wiki relative links
On 07/04/18 16:37, Stephan Beal wrote: i don't _think_ that you can use %2f in a path component and have it apply different semantics than a slash. How would software know to differentiate between the two? That would be similar to expecting a local file name of a\/b to work. (If it did work, it would cause no end of confusion.) Fossil already does apply different semantics. It's simple, but not what you're thinking: As far as I can tell, Fossil rejects URLs containing %xx in the path. Sounds like a good way to avoid people sneaking metacharacters past security filters. Wouldn't want %2e%2e%2f to come up as ../ allowing you to see files outside of the document root! -- Andy Goth | ___ 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] Markdown wiki relative links
i don't _think_ that you can use %2f in a path component and have it apply different semantics than a slash. How would software know to differentiate between the two? That would be similar to expecting a local file name of a\/b to work. (If it did work, it would cause no end of confusion.) - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Wed, Jul 4, 2018, 23:26 Andy Goth wrote: > On 07/04/18 16:01, Stephan Beal wrote: > > Fwiw, a few years back i created a patch which caused generated wiki > > links to always emit wiki/x rather than name=x, but it was pointed out > > to me that wiki/x doesn't work when x contains a slash, which is a valid > > wiki page name character. Thus the portable approach is to use name=x. :/ > > Well, I totally forgot slashes could be in page names. What about %2f? > > -- > Andy Goth | > ___ > 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] Markdown wiki relative links
On 07/04/18 16:01, Stephan Beal wrote: Fwiw, a few years back i created a patch which caused generated wiki links to always emit wiki/x rather than name=x, but it was pointed out to me that wiki/x doesn't work when x contains a slash, which is a valid wiki page name character. Thus the portable approach is to use name=x. :/ Well, I totally forgot slashes could be in page names. What about %2f? -- Andy Goth | ___ 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] Markdown wiki relative links
Fwiw, a few years back i created a patch which caused generated wiki links to always emit wiki/x rather than name=x, but it was pointed out to me that wiki/x doesn't work when x contains a slash, which is a valid wiki page name character. Thus the portable approach is to use name=x. :/ - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Wed, Jul 4, 2018, 22:54 Andy Goth wrote: > To create a link in the Markdown wiki, the syntax is [like this](url). > That's all well and good, but what precisely does url need to be for one > page to link to another? In writing embedded documentation, I've gotten > used to relative paths, so in order to link /doc/trunk/doc/foo.md to > /doc/trunk/doc/bar.md, I write (bar.md). > > However, with the wiki, there's an issue. Most (if not all) of the > links into the wiki use the ...?name=page syntax rather than the > theoretically equivalent .../page syntax. This throws off relative > paths entirely. Relative links between wiki pages will be different > depending on which "equivalent" syntax was used to access the wiki. > > Suppose wiki page foo wants to link to wiki page bar. If foo was > accessed as wiki?name=foo, then it must link to (wiki?name=bar) or > (wiki/bar). But if foo was accessed as wiki/foo, it must link to (bar), > which it what I hoped would work all along. > > To make intra-wiki links work regardless of which syntax is used to > access the wiki, it appears it's necessary to use "absolute" (actually > relative to the project root) paths: (/wiki?name=bar) or (/wiki/bar). > This is not something I've had to deal with (yet?) when doing embedded > documentation. > > My preference would be for Fossil to never send the name query parameter > to the user. If a name query parameter is received from the user, I > think maybe Fossil should not call the webpage function (other than > confirming that one exists) and instead immediately send a 301 Moved > Permanently back to the user to rewrite the URL to use /. > > Or maybe I'm missing something fundamental here. > > There's one other style of relative link I'll mention: (?name=bar). > This replaces the name query parameter. I don't think this would work > very well if linked from /wiki/foo. Also it gets even weirder when > clicking a link in the preview shown by wikiedit, since it takes the > user to the editor for the target page. But this last would still occur > should we replace all ?name= with /. To avoid that, the link would have > to be either (/wiki/bar) or (../wiki/bar), though of course that last > one combines the worst of all worlds. > > For now, I'll make sure all my wiki links are to /wiki/whatever. > > Note: I'm talking about Fossil version 83e3445f67 (2.1), since that's > what Chiselapp uses. > > -- > Andy Goth | > ___ > 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] Markdown in tickets
On 26-6-2018 22:05, Richard Hipp wrote:
> On 6/26/18, Chad Perrin wrote:
>> I see no Markdown formatting option for tickets when visiting the web UI
>> via `fossil serve`:
>
> Go to /Admin/Tickets and edit the scripts you find there to provide
> support for markdown. As the scripts already provide support for
> text/plain, text/html, and text/x-fossil-wiki, it should be apparent
> how to enhance them with an extra case for text/markdown.
Rendering the markdown is not quite that easy: all the existing options
use the "wiki" command, supplied with various incantations of the
tag. This doesn't appear to work for markdown.
Browsing the source code suggests there is a separate "markdown"
command, but that returns a list instead of actually rendering HTML,
like the wiki command does.
> Once you get this working, submit your changes for inclusion in the
> SQLite source tree.
After some spelunking in th_language.c, here’s what I got working to
render the markdown. Setting the proper mimetype and including it as an
option is left as an exercise for the reader.
(...)
if {$mutype eq "Markdown"} {
set md [string trimright $icomment]
set md [markdown $md]
set title [lindex $md 0]
set body [lindex $md 1]
html ""
html $title
html ""
html $body
} elseif {$mutype eq "Wiki"} {
(...)
I’d never written TH1 (or Tcl) before, so it can probably be improved
upon — most notably skipping the if the title is empty, which will
usually be the case in a ticket — but it seems to work OK.
--
Martijn Coppoolse
___
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] Markdown in tickets
On 6/26/18, Chad Perrin wrote: > > I am running Fossil v2.5 here: > > $ fossil version > This is fossil version 2.5 [188a0e2904] 2018-02-07 18:48:14 UTC > > I see no Markdown formatting option for tickets when visiting the web UI > via `fossil serve`: Go to /Admin/Tickets and edit the scripts you find there to provide support for markdown. As the scripts already provide support for text/plain, text/html, and text/x-fossil-wiki, it should be apparent how to enhance them with an extra case for text/markdown. Once you get this working, submit your changes for inclusion in the SQLite source tree. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown in tickets
On Tue, Jun 26, 2018 at 12:05:51PM -0400, Richard Hipp wrote: > On 6/26/18, Andy Goth wrote: > > Is there a reason why Fossil tickets don't allow markdown? The format > > options are wiki, HTML, plain text, and [links only]. > > Markdown as a formatting option can be added by configuration. > > Perhaps you are asking for Markdown support to be added to the default > configuration? I am running Fossil v2.5 here: $ fossil version This is fossil version 2.5 [188a0e2904] 2018-02-07 18:48:14 UTC I see no Markdown formatting option for tickets when visiting the web UI via `fossil serve`: https://i.imgur.com/F3UL8kc.png It only shows Wiki, HTML, Plain Text, and [links only]. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown in tickets
On 06/26/18 11:05, Richard Hipp wrote: On 6/26/18, Andy Goth wrote: Is there a reason why Fossil tickets don't allow markdown? The format options are wiki, HTML, plain text, and [links only]. Markdown as a formatting option can be added by configuration. I apologize, I was unclear. When I was talking about Fossil tickets, I was referring specifically to Fossil's own tickets, rather than tickets in general. Right now I can't use Markdown when writing a ticket (or comment thereto) against Fossil itself. Perhaps you are asking for Markdown support to be added to the default configuration? I don't see a reason to disable it by default. -- Andy Goth | ___ 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] Markdown in tickets
On 6/26/18, Andy Goth wrote: > Is there a reason why Fossil tickets don't allow markdown? The format > options are wiki, HTML, plain text, and [links only]. Markdown as a formatting option can be added by configuration. Perhaps you are asking for Markdown support to be added to the default configuration? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] markdown option missing in dropdown of tickets
On Dec 15, 2016, at 9:18 AM, Aldo Nicolas Bruno wrote: > > I see only: Wiki, HTML, plain-text and [links-only] That is a known-missing feature. I and others have wished for it here on the mailing list. All that’s needed is for someone to want it badly enough to write the code to implement it. It probably isn’t too difficult, just a matter of hooking the ticket feature up to the same formatting code used by the wiki feature. ___ 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] Markdown checkin comments and tickets (was: Multi line formatting)
On Mon, Aug 31, 2015 at 1:56 PM, Warren Young wrote: > On Aug 31, 2015, at 11:46 AM, Warren Young wrote: > > I think we can agree that using hooks to enforce, say, code formatting > rules is a bad idea. > > I did a bit of Googling, and this blog article describes what seems to be > a well thought out system for Git: > > > http://causes.github.io/blog/2013/05/30/overcommit-the-opinionated-git-hook-manager/ > > The key is doing the checks locally, rather than on the central repo > server, and offering a way to bypass the checks at need. We put our source code checks into the build process. Yes, that means they could be easily by-passed, but if some one did that, other team members would see the failures. ___ 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] Markdown checkin comments and tickets (was: Multi line formatting)
On Aug 31, 2015, at 11:46 AM, Warren Young wrote: > > On Aug 31, 2015, at 11:39 AM, Stephan Beal wrote: >> >> Hooks are not just about emails, but about policy decisions. "Does this file >> conform to XYZ." A failure at that level is unrecoverable without changing >> the policy. > > I think we can agree that using hooks to enforce, say, code formatting rules > is a bad idea. I did a bit of Googling, and this blog article describes what seems to be a well thought out system for Git: http://causes.github.io/blog/2013/05/30/overcommit-the-opinionated-git-hook-manager/ The key is doing the checks locally, rather than on the central repo server, and offering a way to bypass the checks at need. ___ 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] Markdown checkin comments and tickets (was: Multi line formatting)
On Aug 31, 2015, at 11:39 AM, Stephan Beal wrote: > > Hooks are not just about emails, but about policy decisions. "Does this file > conform to XYZ." A failure at that level is unrecoverable without changing > the policy. I think we can agree that using hooks to enforce, say, code formatting rules is a bad idea. Now, maybe a hook could give a *warning* that you’ve just checked a C++ file in with tabs instead of spaces, but it shouldn’t refuse outright, because of the very risk you refer to. I’m going to guess that if you set hooks on a repo sitting behind “fossil server”, that those hook scripts don’t get sent down to a clone, or may not run of they do, so you can’t count on them being run locally before we get to the push stage? ___ 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] Markdown checkin comments and tickets (was: Multi line formatting)
On Mon, Aug 31, 2015 at 7:27 PM, Warren Young wrote: > > That becomes fossil's problem > > No, it’s the hook-writer’s problem. > > The hook-writer solves that in the normal way: log the problem so that a > human can figure out how to solve it, then retry the commit. > Hooks are not just about emails, but about policy decisions. "Does this file conform to XYZ." A failure at that level is unrecoverable without changing the policy. > > Many commercial/enterprise environments don't allow this. We once, after > 8 months of development using 'maven' as a build tool, had to port > everything to ant after discovering that the remote site does not allow > external internet access (in or out). > > How do you imagine such a problem could bite a Fossil user? > Now that you mention it... i can't, unless it allows inbound but no outbound traffic (one bank i worked at has some network segments set up that way). > Case 2: They have a perfectly working Fossil setup with hooks, then 8 > months later they move it to a new remote site, and it fails immediately > because none of the hook scripts will run. Now they get to choose whether > to disable hooks or solve the site restriction. Solve == remove, as the code is already committed and fossil disallows history changes. > If they choose the first option, Fossil goes back to working the same > way it does everywhere else, which I think we can agree to summarize as, > “Adequate,” at the least. :) > Adequate, but troubling nonetheless. > Hooks are optional. They may add site-specific restrictions, but > bypassing these restrictions does not harm the Fossil DB. > Not the db, but the constellation. They leave the "violating" user in a state which is no longer mergeable with the main repo. > I imagine some people will try to use hooks to create inviolable > constraints, but that’s predicated on those hooks actually running, and not > being bypassable. That’s purely a local administration problem, not > something that the Fossil project has to solve. > Agreed, but this list is the first place they'll run when such a policy forks them from their main repo, asking for advice on how to solve it. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown checkin comments and tickets (was: Multi line formatting)
On Aug 31, 2015, at 10:59 AM, Joe Mistachkin wrote: > > > There are docs on --with-tcl and the commands it provides (see th1.md in the > source tree). Yes, I already saw that, via the web: http://fossil-scm.org/index.html/doc/tip/www/th1.md You have to admit, it’s awfully thin on details. How exactly do you use this to set a hook, for one thing? If I want to run an external command, does --with-tcl let me call Tcl’s “exec” directly, or do I need to call “tclEval exec”, or something else? I’m sure I could figure all this out by reading Fossil’s source and experimenting, but I think it’s fair to expect the docs to cover such basics. > Also, with Tcl enabled the hooks work perfectly for sending mail I think the mere existence of a tutorial article that builds a basic “send email on each commit” hook would be enough to solve a lot of people’s problems. Just something to riff off of, you know? ___ 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] Markdown checkin comments and tickets (was: Multi line formatting)
On Aug 31, 2015, at 10:46 AM, Stephan Beal wrote: > > The push fails because a remote hook disallows it. What then? The same thing that happens when you try to push to a read-only repo, or push while the Internet connection is down, or push to a repo you accidentally cloned anonymously by forgetting user@ in the URL, or push to a server that’s just run out of disk space, or… Fossil already has to cope with such problems. > That becomes fossil's problem No, it’s the hook-writer’s problem. The hook-writer solves that in the normal way: log the problem so that a human can figure out how to solve it, then retry the commit. This is part of what I was implying when I spoke of a CGI-like hook calling protocol. If you try an HTTP POST to a site you aren’t logged into, it will likely give you a 400-series error along with some error text, which tells you what happened and gives you a clue how to fix it. In the same way, an external Fossil hook program can return some error code and a string that makes its way from the remote host to the local Fossil client. > Many commercial/enterprise environments don't allow this. We once, after 8 > months of development using 'maven' as a build tool, had to port everything > to ant after discovering that the remote site does not allow external > internet access (in or out). How do you imagine such a problem could bite a Fossil user? Case 1: They add a hook to the remote server, it fails, so they remove it, and Fossil goes back to running. No 8-month submarine time. Case 2: They have a perfectly working Fossil setup with hooks, then 8 months later they move it to a new remote site, and it fails immediately because none of the hook scripts will run. Now they get to choose whether to disable hooks or solve the site restriction. If they choose the first option, Fossil goes back to working the same way it does everywhere else, which I think we can agree to summarize as, “Adequate,” at the least. :) Hooks are optional. They may add site-specific restrictions, but bypassing these restrictions does not harm the Fossil DB. I imagine some people will try to use hooks to create inviolable constraints, but that’s predicated on those hooks actually running, and not being bypassable. That’s purely a local administration problem, not something that the Fossil project has to solve. ___ 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] Markdown checkin comments and tickets (was: Multi line formatting)
There are docs on --with-tcl and the commands it provides (see th1.md in the source tree). Also, with Tcl enabled the hooks work perfectly for sending mail and I've personally been doing so for several years on a repository of mine. Sent from my iPhone > On Aug 31, 2015, at 9:40 AM, Warren Young wrote: > >> On Aug 30, 2015, at 2:27 AM, Stephan Beal wrote: >> >>> On Sun, Aug 30, 2015 at 10:15 AM, Baptiste Daroussin >>> wrote: >>> Number #1 is the inhability to run "external" hooks easily >> >> it's difficult to do portably > > system() is ANSI C. > > There are many external programs you can call that way. All that’s needed is > some kind of hook-calling protocol, a la CGI. > >> it opens up many more potential failure cases > > I don’t see what’s difficult about failing a transaction if a hook is defined > and the external program call fails. All the difficult parts are fobbed off > on the person writing the hook script. > >> what happens to a commit if an http connection to an external server, used >> by a trigger, cannot be established? > > The commit fails, same as if the process of attempting the commit causes any > other error, such as a fork without --allow-fork. > >> Many hosting environments do not allow hosted scripts/apps to establish >> outbound connections with external servers > > If you’re on such a host, you don’t get to use hooks. Switch to a different > hosting provider if you need hooks. There are dozens of bare-bones VPS and > cloud hosting providers without this restriction. > > Also, this restriction only affects those who go out of their way to use > hooks. If you don’t define any hooks, Fossil will behave the same as it does > today. > >> Fossil does have basic hooks support in the form of TH1/TCL scripts, > > You have to configure Fossil with --with-th1-hooks to enable it. > > Also, as far as I can tell, TH1 doesn’t have the power to implement an SMTP > client or call out to an external one anyway. (i.e. no equivalent of > connect(2) or system(3).) > > I was curious how Git handles this, and to a first approximation, it doesn’t. > It includes a 1,700 line Perl script which either calls out to sendmail(1) > or uses the Perl Net::SMTP library to do all the heavy lifting. > >https://github.com/git/git/blob/master/git-send-email.perl > > My point above is that even these options aren’t available to TH1. > > I see that Fossil has --with-tcl, which might be able to solve this, but I > don’t see any documentation explaining it on the Fossil site. > >> There is no _portable_ external provider API for sending mails. > > Not for C, true, but Tcl can do it: http://wiki.tcl.tk/1256 > > For platforms where linking to Tcl isn’t suitable, TH1 could add the exec and > open commands: > > https://www.tcl.tk/man/tcl8.5/tutorial/Tcl26.html > > Then Fossil proper wouldn’t have to worry about such things as how to send > email. > >> My point was not so much about the multiline support, but the lack (in my >> experience) of need for book-length commit messages. Without those, the lack >> of multi-line support is moot. > > Straw man. Adding a small bit of markup to a commit message is not writing > books. And it’s a good thing, since Markdown is not the right formatting > system for book production anyway. > > Most of the code needed to do this is in Fossil already. > ___ > 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] Markdown checkin comments and tickets (was: Multi line formatting)
On Mon, Aug 31, 2015 at 6:40 PM, Warren Young wrote: > On Aug 30, 2015, at 2:27 AM, Stephan Beal wrote: > > it opens up many more potential failure cases > > I don’t see what’s difficult about failing a transaction if a hook is > defined and the external program call fails. All the difficult parts are > fobbed off on the person writing the hook script. > i make a commit locally. i push. The push fails because a remote hook disallows it. What then? How do we resolve my repo's discrepancy at that point? That becomes fossil's problem because people will (rightfully) want to retain the data they just committed. > > what happens to a commit if an http connection to an external server, > used by a trigger, cannot be established? > > The commit fails, same as if the process of attempting the commit causes > any other error, such as a fork without --allow-fork. > The _push_ fails. The commit has long-since happened locally. > > Many hosting environments do not allow hosted scripts/apps to establish > outbound connections with external servers > > If you’re on such a host, you don’t get to use hooks. Switch to a > different hosting provider if you need hooks. There are dozens of > bare-bones VPS and cloud hosting providers without this restriction. > Many commercial/enterprise environments don't allow this. We once, after 8 months of development using 'maven' as a build tool, had to port everything to ant after discovering that the remote site does not allow external internet access (in or out). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown checkin comments and tickets (was: Multi line formatting)
On Aug 30, 2015, at 2:27 AM, Stephan Beal wrote: > > On Sun, Aug 30, 2015 at 10:15 AM, Baptiste Daroussin > wrote: > > Number #1 is the inhability to run "external" hooks easily > > it's difficult to do portably system() is ANSI C. There are many external programs you can call that way. All that’s needed is some kind of hook-calling protocol, a la CGI. > it opens up many more potential failure cases I don’t see what’s difficult about failing a transaction if a hook is defined and the external program call fails. All the difficult parts are fobbed off on the person writing the hook script. > what happens to a commit if an http connection to an external server, used by > a trigger, cannot be established? The commit fails, same as if the process of attempting the commit causes any other error, such as a fork without --allow-fork. > Many hosting environments do not allow hosted scripts/apps to establish > outbound connections with external servers If you’re on such a host, you don’t get to use hooks. Switch to a different hosting provider if you need hooks. There are dozens of bare-bones VPS and cloud hosting providers without this restriction. Also, this restriction only affects those who go out of their way to use hooks. If you don’t define any hooks, Fossil will behave the same as it does today. > Fossil does have basic hooks support in the form of TH1/TCL scripts, You have to configure Fossil with --with-th1-hooks to enable it. Also, as far as I can tell, TH1 doesn’t have the power to implement an SMTP client or call out to an external one anyway. (i.e. no equivalent of connect(2) or system(3).) I was curious how Git handles this, and to a first approximation, it doesn’t. It includes a 1,700 line Perl script which either calls out to sendmail(1) or uses the Perl Net::SMTP library to do all the heavy lifting. https://github.com/git/git/blob/master/git-send-email.perl My point above is that even these options aren’t available to TH1. I see that Fossil has --with-tcl, which might be able to solve this, but I don’t see any documentation explaining it on the Fossil site. > There is no _portable_ external provider API for sending mails. Not for C, true, but Tcl can do it: http://wiki.tcl.tk/1256 For platforms where linking to Tcl isn’t suitable, TH1 could add the exec and open commands: https://www.tcl.tk/man/tcl8.5/tutorial/Tcl26.html Then Fossil proper wouldn’t have to worry about such things as how to send email. > My point was not so much about the multiline support, but the lack (in my > experience) of need for book-length commit messages. Without those, the lack > of multi-line support is moot. Straw man. Adding a small bit of markup to a commit message is not writing books. And it’s a good thing, since Markdown is not the right formatting system for book production anyway. Most of the code needed to do this is in Fossil already. ___ 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] Markdown checkin comments and tickets (was: Multi line formatting)
Good support for sending email would be wonderful. We are getting along by running rss2email, far from ideal but adequate. On Sun, Aug 30, 2015, 1:55 AM Baptiste Daroussin < baptiste.darous...@gmail.com> wrote: > 2015-08-30 10:27 GMT+02:00 Stephan Beal : > > On Sun, Aug 30, 2015 at 10:15 AM, Baptiste Daroussin > > wrote: > >> > >> Number #1 is the inhability to run "external" hooks easily, like > >> execute this script each time a sync is done, for before checking in, > >> run this scripts. (personnally I can live with that) > > > > > > Management summary: that's primarily because (A) it's difficult to do > > portably in a small package like Fossil and (B) because it opens up many > > more potential failure cases than currently exist. (e.g. what happens to > a > > commit if an http connection to an external server, used by a trigger, > > cannot be established?) Many hosting environments do not allow hosted > > scripts/apps to establish outbound connections with external servers, > which > > inherently castrates such features, as well as your next one... > > > > That said, Fossil does have basic hooks support in the form of TH1/TCL > > scripts, but i've never used them. Jan or Joe can certainly say more > about > > them. > > > > Well last I tried there were not really useful and as for example in > case of post bug report because of them being run with reporters > (whcih makes sense given how they are designed) they were limited > deeply limited in what they could do... I end it up back in the time > at making them just to a http call to a local cgi which will then run > a bunch complex fossil cli command to be able to grab the information > I need (and send mails) it was in the end so complicated I gave up and > switched the repo to github back in the time :( > > >> > >> Number #3 can be related soehow to number #1 is the inability of the > >> bug tracker to send mails. > > > > > > Right - very closely related. Speaking to diverse mail servers reliably > is > > difficult to implement, and really needs an external mail API provider. > > There is no _portable_ external provider API for sending mails. Doing so > on > > Unix, via sendmail, is simple enough, but fossil aims to provide all of > its > > features on all of its platforms, insofar as possible. (AFAIK, symlinks > is > > the only feature which doesn't achieve this ideal.) IMO this is the right > > approach - limit fossil to features which are only available on all of > its > > platforms (AFAIK i'm one of the few here who believes, for that reason, > that > > fossil should not support symlinks). > > > >> > >> Well my experience is quite the opposite. Most if not all projects I > >> have been working relies on multi line logs. On some of them like all > >> FreeBSD's repositories (svn and git) I cannot even imagine getting > >> though history without multi time view. > > > > > > My point was not so much about the multiline support, but the lack (in my > > experience) of need for book-length commit messages. Without those, the > lack > > of multi-line support is moot. > > > >> Maybe that could be done via a new "log" which will be a kind of alias > >> for fossil timeline -t ci ? (seriously when you come from other VCS > >> the fossil timeline is disturbing :D) > > > > > > Personally, i've always been against Fossil doing _any_ sort of > manipulation > > of commit message storage or display (e.g. word-wrapping in the > console), as > > it adds a disproportionate amount of complexity. If someone can read > > programming code, they can certainly read commit messages, regardless of > > their formatting. But i am likely in the minority on that point. > > > I 100% agree with you here, if fossil was not manipulating the message > on display the multiline formatting would work out of box (they are > correctly stored) > > Bapt > ___ > 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] Markdown checkin comments and tickets (was: Multi line formatting)
2015-08-30 10:27 GMT+02:00 Stephan Beal : > On Sun, Aug 30, 2015 at 10:15 AM, Baptiste Daroussin > wrote: >> >> Number #1 is the inhability to run "external" hooks easily, like >> execute this script each time a sync is done, for before checking in, >> run this scripts. (personnally I can live with that) > > > Management summary: that's primarily because (A) it's difficult to do > portably in a small package like Fossil and (B) because it opens up many > more potential failure cases than currently exist. (e.g. what happens to a > commit if an http connection to an external server, used by a trigger, > cannot be established?) Many hosting environments do not allow hosted > scripts/apps to establish outbound connections with external servers, which > inherently castrates such features, as well as your next one... > > That said, Fossil does have basic hooks support in the form of TH1/TCL > scripts, but i've never used them. Jan or Joe can certainly say more about > them. > Well last I tried there were not really useful and as for example in case of post bug report because of them being run with reporters (whcih makes sense given how they are designed) they were limited deeply limited in what they could do... I end it up back in the time at making them just to a http call to a local cgi which will then run a bunch complex fossil cli command to be able to grab the information I need (and send mails) it was in the end so complicated I gave up and switched the repo to github back in the time :( >> >> Number #3 can be related soehow to number #1 is the inability of the >> bug tracker to send mails. > > > Right - very closely related. Speaking to diverse mail servers reliably is > difficult to implement, and really needs an external mail API provider. > There is no _portable_ external provider API for sending mails. Doing so on > Unix, via sendmail, is simple enough, but fossil aims to provide all of its > features on all of its platforms, insofar as possible. (AFAIK, symlinks is > the only feature which doesn't achieve this ideal.) IMO this is the right > approach - limit fossil to features which are only available on all of its > platforms (AFAIK i'm one of the few here who believes, for that reason, that > fossil should not support symlinks). > >> >> Well my experience is quite the opposite. Most if not all projects I >> have been working relies on multi line logs. On some of them like all >> FreeBSD's repositories (svn and git) I cannot even imagine getting >> though history without multi time view. > > > My point was not so much about the multiline support, but the lack (in my > experience) of need for book-length commit messages. Without those, the lack > of multi-line support is moot. > >> Maybe that could be done via a new "log" which will be a kind of alias >> for fossil timeline -t ci ? (seriously when you come from other VCS >> the fossil timeline is disturbing :D) > > > Personally, i've always been against Fossil doing _any_ sort of manipulation > of commit message storage or display (e.g. word-wrapping in the console), as > it adds a disproportionate amount of complexity. If someone can read > programming code, they can certainly read commit messages, regardless of > their formatting. But i am likely in the minority on that point. > I 100% agree with you here, if fossil was not manipulating the message on display the multiline formatting would work out of box (they are correctly stored) Bapt ___ 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] Markdown checkin comments and tickets (was: Multi line formatting)
On Sun, Aug 30, 2015 at 10:15 AM, Baptiste Daroussin < baptiste.darous...@gmail.com> wrote: > Number #1 is the inhability to run "external" hooks easily, like > execute this script each time a sync is done, for before checking in, > run this scripts. (personnally I can live with that) > Management summary: that's primarily because (A) it's difficult to do portably in a small package like Fossil and (B) because it opens up many more potential failure cases than currently exist. (e.g. what happens to a commit if an http connection to an external server, used by a trigger, cannot be established?) Many hosting environments do not allow hosted scripts/apps to establish outbound connections with external servers, which inherently castrates such features, as well as your next one... That said, Fossil does have basic hooks support in the form of TH1/TCL scripts, but i've never used them. Jan or Joe can certainly say more about them. > Number #3 can be related soehow to number #1 is the inability of the > bug tracker to send mails. Right - very closely related. Speaking to diverse mail servers reliably is difficult to implement, and really needs an external mail API provider. There is no _portable_ external provider API for sending mails. Doing so on Unix, via sendmail, is simple enough, but fossil aims to provide all of its features on all of its platforms, insofar as possible. (AFAIK, symlinks is the only feature which doesn't achieve this ideal.) IMO this is the right approach - limit fossil to features which are only available on all of its platforms (AFAIK i'm one of the few here who believes, for that reason, that fossil should not support symlinks). > Well my experience is quite the opposite. Most if not all projects I > have been working relies on multi line logs. On some of them like all > FreeBSD's repositories (svn and git) I cannot even imagine getting > though history without multi time view. > My point was not so much about the multiline support, but the lack (in my experience) of need for book-length commit messages. Without those, the lack of multi-line support is moot. Maybe that could be done via a new "log" which will be a kind of alias > for fossil timeline -t ci ? (seriously when you come from other VCS > the fossil timeline is disturbing :D) > Personally, i've always been against Fossil doing _any_ sort of manipulation of commit message storage or display (e.g. word-wrapping in the console), as it adds a disproportionate amount of complexity. If someone can read programming code, they can certainly read commit messages, regardless of their formatting. But i am likely in the minority on that point. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown checkin comments and tickets (was: Multi line formatting)
2015-08-30 4:35 GMT+02:00 Stephan Beal : > On Sun, Aug 30, 2015 at 4:27 AM, Warren Young wrote: >> >> On Aug 29, 2015, at 8:58 AM, Baptiste Daroussin >> wrote: >> > >> > the number 2 major complaints I heard from user >> >> Really? What’s #1 and #3? :) > > > +1 > Number #1 is the inhability to run "external" hooks easily, like execute this script each time a sync is done, for before checking in, run this scripts. (personnally I can live with that) Number #3 can be related soehow to number #1 is the inability of the bug tracker to send mails. Which makes the casual reporter never reply to comments on their bug reports. Making interraction quite complicated with them. (This one is a huge pain for me and made me switch some of projects to github when they became popular :() While I'm here Number #4 is the inhability to have a equivalent of git am (getting a preformatted checkin which one can directly add on a repository to preserve the author of the checki) Personnally I do not feel that is it that important, it is simply sugar IMHO. > In some 20 years (as of this coming winter) of using source control (RCS => > CVS => SVN => Fossil), i can count on one hand the number of times i've seen > commit messages (in project i work on/contribute to) which span more than > two sentences. (Anything needing a longer explanation simply gets a ticket > number as the commit message.) i can count on 0 fingers the number of times > i have written a formatted-for-management commit message. > Well my experience is quite the opposite. Most if not all projects I have been working relies on multi line logs. On some of them like all FreeBSD's repositories (svn and git) I cannot even imagine getting though history without multi time view. If something is able to do multi-line formatting by default it works fine with one liners project, but something only able to format one line is broken for multi-line cases :( Maybe that could be done via a new "log" which will be a kind of alias for fossil timeline -t ci ? (seriously when you come from other VCS the fossil timeline is disturbing :D) Best regards, Bapt ___ 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] Markdown checkin comments and tickets (was: Multi line formatting)
On Sun, Aug 30, 2015 at 4:43 AM, Warren Young wrote: > Well, you may have noticed that I can be verbose. :) > This is the first project i've been on where the topic has even come up. > Also, I think the tendency for a single commit to do multiple things is > more common in single-person projects, where the pressure to use branches > for complicated changes is lower. > > When you’re working on an experimental branch, it’s easy to commit early > and often, since you aren’t affecting anything else, whereas when you’re > working on the trunk, you tend to wait to commit until the feature is > perfect. Functionality accumulates, so that by the time it comes time to > check it all in, it takes a bit of work to explain what it all does. > In which case something like my two-week-long commit at work last Friday typically suffices: "Implemented Jira ticket PROJ-1234." ;) All other details were attached to the ticket (and, even there, nobody's ever really gonna read them). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown checkin comments and tickets (was: Multi line formatting)
On Aug 29, 2015, at 8:35 PM, Stephan Beal wrote: > > i can count on one hand the number of times i've seen commit messages (in > project i work on/contribute to) which span more than two sentences. Well, you may have noticed that I can be verbose. :) Also, I think the tendency for a single commit to do multiple things is more common in single-person projects, where the pressure to use branches for complicated changes is lower. When you’re working on an experimental branch, it’s easy to commit early and often, since you aren’t affecting anything else, whereas when you’re working on the trunk, you tend to wait to commit until the feature is perfect. Functionality accumulates, so that by the time it comes time to check it all in, it takes a bit of work to explain what it all does. ___ 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] Markdown checkin comments and tickets (was: Multi line formatting)
On Sun, Aug 30, 2015 at 4:27 AM, Warren Young wrote: > On Aug 29, 2015, at 8:58 AM, Baptiste Daroussin < > baptiste.darous...@gmail.com> wrote: > > > > the number 2 major complaints I heard from user > > Really? What’s #1 and #3? :) > +1 In some 20 years (as of this coming winter) of using source control (RCS => CVS => SVN => Fossil), i can count on one hand the number of times i've seen commit messages (in project i work on/contribute to) which span more than two sentences. (Anything needing a longer explanation simply gets a ticket number as the commit message.) i can count on 0 fingers the number of times i have written a formatted-for-management commit message. Wiki markup is a bit overkill when all you want is the occasional > `literal`, and it’s confusing to switch between Markdown and Wiki links, > since their order of URL/text is opposite. > +1 -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown checkin comments and tickets (was: Multi line formatting)
On Aug 29, 2015, at 8:58 AM, Baptiste Daroussin wrote: > > the number 2 major complaints I heard from user Really? What’s #1 and #3? :) I find that setting the “block formatting” option in Admin/Settings/Timeline solves most of my problems in this area. I don’t mind that Fossil’s block formatting rules assume single hard LFs are soft line breaks, or that it only inserts hard paragraph breaks on double LF. This is the same rule used by Markdown, so it’s not even something I have to actively think about any more; it’s just how plain text -> web text works in my brain now. In fact, I’d welcome a feature that allowed Markdown-formatted checkin comments. Not because I spend a lot of time making my checkin comments pretty, but because it would occasionally [be helpful](http://www.wikihow.com/Be-Helpful). :) Actually, I think my main use of Markdown-formatted checkin comments would be bullet lists, for those really complicated checkins that do several related things. And while I’m wishing, an option for Markdown-formatted tickets would be nice, too. Wiki markup is a bit overkill when all you want is the occasional `literal`, and it’s confusing to switch between Markdown and Wiki links, since their order of URL/text is opposite. ___ 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] Markdown
On May 28, 2014 2:31 PM, "Warren Young" wrote:
>{deleted stuff}
> The attached Fossil repo also contains a copy of the official Markdown
documentation. It was included in the test suite, so I linked to it from
the repo's wiki, rather than remove it.
>
Thanks very much for the effort!
___
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] Markdown
On Wed, May 28, 2014 at 12:05 PM, Warren Young wrote: > On 5/27/2014 22:58, Scott Robison wrote: > >> The best I can come up with for a link to a >> wiki page (from another wiki page) is something like >> "[Page](wiki?name=Page)" which really seems kinda ugly >> > > You probably want this syntax: > > [Page][1] > > > later, typically at end of doc... > > [1]: wiki?name=Page > Thanks. I did realize I could use [Page](wiki/Page) which is better if I just want to do it inline. The footnote style is good to know as well. Still, I've read various things online about "what markdown does fossil support" and I've read something like "vanilla markdown plus some form tables extension". It would be nice to have a very central place (like a wiki page on the fossil repo) that says "Here is the definitive list of what markdown use can use on fossil". I'm beginning to think the only place that documentation exists is in the code (which is fine, no one owes me an explanation for free software). Is this the case? -- Scott Robison ___ 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] Markdown
On 5/27/2014 22:58, Scott Robison wrote: The best I can come up with for a link to a wiki page (from another wiki page) is something like "[Page](wiki?name=Page)" which really seems kinda ugly You probably want this syntax: [Page][1] later, typically at end of doc... [1]: wiki?name=Page ___ 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] Markdown rules for Fossil Wiki
On Tue, 13 May 2014 11:49:32 -0700 Gerald Gutierrez wrote: > I can use the [thename](target_link) markdown style, but that is a > generic link and I seem to have to specify the full link and not just > the wiki page name. I use [Page name](wiki?name=Page name) to reference internal wiki pages in Markdown. -- Nikola Kotur signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown
On Sun, 5 Jan 2014 14:23:34 +0100 Natacha Porté wrote: Hiya Natacha, > I'm the one to blame for fossil's implementation, and what ended up in > trunk implements only "official" markdown, with > PHP-markdown-extra-styled tables as only extension. Why blame? You have to be congratulated!! The markdown-wiki topic was brought in Nov '09 and I jumped to it ~6months later after discovering Fossil. > The reason for that is that it started out as a minimal > proof-of-concept, and then noone has been vocal enough to bring a > feature-request to my attention (except for making absolute links > not-so-absolute). I'm sorry for not being included in the discussion, probably it was during the phase when I was not using Fossil a lot and/or not following mailing list. These days I mostly settled on (light) using of Git, but Fossil's simplicity still fascinates me and that's why I periodically re-evaluating it. I still miss some things like ability to do immediate uncommit after some silly mistakes (like forgetting add/rm some files, wrong message etc.), as well as ability to selectivley scrub unneeded private branches. Sometimes, I also like to be able to rebase and tweak my commits before pushing to the public repo. However, having markdown in wiki brings nice 'pros' to Fossil. > If anything more is needed, I can probably do it, though it might have > to wait a bit until I'm less overwhelmed by stuff that keep my > paychecks coming. For some of my web needs I use Nikola (python static generator) which support python's implementation of markdown (https://pypi.python.org/pypi/Markdown) as well as Pandoc's implementation (e.g. http://oopsmonk.blogspot.com/2013/05/pandocs-markdown-reference.html). I must say that I prefer to use reST for documentation, but for shorter stuff markdown might be good-enough. So, I'll take a closer look and see what I'd consider 'missing features' and report back here. Sincerely, Gour -- As the embodied soul continuously passes, in this body, from boyhood to youth to old age, the soul similarly passes into another body at death. A sober person is not bewildered by such a change. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown
Hello, on Sunday 05 January 2014 at 13:06, Gour wrote: > On Sun, 5 Jan 2014 01:05:57 -0600 > Jonathan Otsuka wrote: > > > You can use the as a starting guide: > > > > http://daringfireball.net/projects/markdown/ > > Thanks. I know about that but wonder about fossil's implementation. Some > more details? I'm the one to blame for fossil's implementation, and what ended up in trunk implements only "official" markdown, with PHP-markdown-extra-styled tables as only extension. The reason for that is that it started out as a minimal proof-of-concept, and then noone has been vocal enough to bring a feature-request to my attention (except for making absolute links not-so-absolute). If anything more is needed, I can probably do it, though it might have to wait a bit until I'm less overwhelmed by stuff that keep my paychecks coming. Hoping this helps, Natacha Porté pgp6oarSBKsuJ.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] Markdown
On Sun, 5 Jan 2014 01:05:57 -0600 Jonathan Otsuka wrote: > You can use the as a starting guide: > > http://daringfireball.net/projects/markdown/ Thanks. I know about that but wonder about fossil's implementation. Some more details? Sincerely, Gour -- The humble sages, by virtue of true knowledge, see with equal vision a learned and gentle brāhmana, a cow, an elephant, a dog and a dog-eater. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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] Markdown
I was caught off guard since I saw my email your reply. You can use the as a starting guide: http://daringfireball.net/projects/markdown/ Jonathan Otsuka > On Jan 4, 2014, at 11:10 PM, Gour wrote: > > On Wed, 24 Jul 2013 10:46:01 -0500 > djg...@gmail.com wrote: > >> Didn't read the change notes for 1.26 until a couple days ago. I just >> noticed that markdown is now turned on by default this is awesome! > > I'ts beginning of New Year and another opportunity to re-evaluate > Fossil...having Markdown I very nice feature, but I wonder where one can > find some docs about its usage, what kind of 'dialect' is supported > etc.? > > I was looking in the wiki, but didn't find much. > > > Sincerely, > Gour > > -- > One must deliver himself with the help of his mind, and not > degrade himself. The mind is the friend of the conditioned soul, > and his enemy as well. > > http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 > > > ___ > 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] Markdown
On Wed, 24 Jul 2013 10:46:01 -0500 djg...@gmail.com wrote: > Didn't read the change notes for 1.26 until a couple days ago. I just > noticed that markdown is now turned on by default this is awesome! I'ts beginning of New Year and another opportunity to re-evaluate Fossil...having Markdown I very nice feature, but I wonder where one can find some docs about its usage, what kind of 'dialect' is supported etc.? I was looking in the wiki, but didn't find much. Sincerely, Gour -- One must deliver himself with the help of his mind, and not degrade himself. The mind is the friend of the conditioned soul, and his enemy as well. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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] Markdown
El 29/05/2013 06:28, "Jonathan Otsuka" escribió: > > Downloads are not compiled with --markdown (its still experimental) you will need to checkout and compile fossil with --markdown yourself. Beware that --mardown is not a configure option anymore, in trunk, so it will be enabled by default in future releases. > > Jonathan Otsuka > > On May 28, 2013, at 10:29 PM, Doug Franklin wrote: > > > Do the default (downloadable) versions of Fossil not have Markdown support enabled, or am I doing something wrong? My browser keeps telling me "open or save this unknown file type". > > > > -- > > Thanks, > > DougF (KG4LMZ) > > ___ > > fossil-users mailing list > > fossil-users@lists.fossil-scm.org > > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown
Downloads are not compiled with --markdown (its still experimental) you will need to checkout and compile fossil with --markdown yourself. Jonathan Otsuka On May 28, 2013, at 10:29 PM, Doug Franklin wrote: > Do the default (downloadable) versions of Fossil not have Markdown support > enabled, or am I doing something wrong? My browser keeps telling me "open or > save this unknown file type". > > -- > Thanks, > DougF (KG4LMZ) > ___ > 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] Markdown engine integrated into fossil
On 2012-07-09 15:41, Richard Hipp wrote: On Mon, Jul 9, 2012 at 3:31 AM, Baptiste Daroussin wrote: 2012/6/7 Richard Hipp : My priority is to get WYSIWYG wiki editing going, at which point the underlying wiki formatting language becomes largely irrelevant, no? Far from criticising your decision to write such an editor, I offer the observation that If a markdown jquery editor would be used, then the available markdown library could be used for rendering, jquery for client side Since we are using it anyway. Those wysiwyg markdown editors are available and leave us only with interfacing/integration. The maintenance burden on the editor is not with us And, maybe, we can offer a migration path for existing wiki and/or embedded documentation? D. Richard Hipp d...@sqlite.org [5] -- 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] Markdown engine integrated into fossil
On Mon, Jul 9, 2012 at 3:41 PM, Richard Hipp wrote: > Yeah. Unfortunately, no actual code writing took place at the "code > sprint." Though lots of cool ideas were exchanged and developed! > i think this particular one probably got forgotten because none of those present are among the markdown advocates :/. My priority is to get WYSIWYG wiki editing going, at which point the >> underlying wiki formatting language becomes largely irrelevant, no? > > If we do the custom pages first, wysiwyg could be built as a custom page (i think). i'm still hashing out ideas on paper for those, but two separate hand/elbow ailments (one right, one left) have been slowing me down the past few days :(. -- - 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] Markdown engine integrated into fossil
2012/7/9 Richard Hipp : > > > On Mon, Jul 9, 2012 at 3:31 AM, Baptiste Daroussin > wrote: >> >> 2012/6/7 Richard Hipp : >> > >> > >> > On Thu, Jun 7, 2012 at 12:10 PM, Baptiste Daroussin >> > wrote: >> >> >> >> Is there any status on this? rejected ? still under review ? >> > >> > >> > DRH swamped. But it is on the list of potential changes for the Fossil >> > Code >> > Sprint in Munich on July 3! >> > >> >> Reading at the feeback from Munich, this obviously didn't happened :) > > > Yeah. Unfortunately, no actual code writing took place at the "code > sprint." Though lots of cool ideas were exchanged and developed! > Yeah I've seen that :). > >> >> is there still plan on it, (btw the library seems to have been fully >> renamed to libsoldout) > > > There are lots of nice features that people want, but I have limited time to > work on them. Perhaps there can be volunteers. > She volunteers and did the job :) > My priority is to get WYSIWYG wiki editing going, at which point the > underlying wiki formatting language becomes largely irrelevant, no? > Not for me as I want to use "in trunk" documentation, and edit it with my favorite $EDITOR :) WYSIWYG doesn't fit my needs at all, plus I have some automated chains using markdown, so having my documentation written only once would be great. Anyway I can wait or live without it, just it will easier maintaining some of my projects. regards, Bapt ___ 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] Markdown engine integrated into fossil
On Mon, Jul 9, 2012 at 3:31 AM, Baptiste Daroussin < baptiste.darous...@gmail.com> wrote: > 2012/6/7 Richard Hipp : > > > > > > On Thu, Jun 7, 2012 at 12:10 PM, Baptiste Daroussin > > wrote: > >> > >> Is there any status on this? rejected ? still under review ? > > > > > > DRH swamped. But it is on the list of potential changes for the Fossil > Code > > Sprint in Munich on July 3! > > > > Reading at the feeback from Munich, this obviously didn't happened :) > Yeah. Unfortunately, no actual code writing took place at the "code sprint." Though lots of cool ideas were exchanged and developed! > is there still plan on it, (btw the library seems to have been fully > renamed to libsoldout) > There are lots of nice features that people want, but I have limited time to work on them. Perhaps there can be volunteers. My priority is to get WYSIWYG wiki editing going, at which point the underlying wiki formatting language becomes largely irrelevant, no? > > Sorry for insisting on this features, but I would love so much to be > able to write my documentation in markdown :D > > regards, > Bapt > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown engine integrated into fossil
2012/6/7 Richard Hipp : > > > On Thu, Jun 7, 2012 at 12:10 PM, Baptiste Daroussin > wrote: >> >> Is there any status on this? rejected ? still under review ? > > > DRH swamped. But it is on the list of potential changes for the Fossil Code > Sprint in Munich on July 3! > Reading at the feeback from Munich, this obviously didn't happened :) is there still plan on it, (btw the library seems to have been fully renamed to libsoldout) Sorry for insisting on this features, but I would love so much to be able to write my documentation in markdown :D regards, Bapt ___ 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] Markdown engine integrated into fossil
On Fri, Jun 8, 2012 at 3:30 AM, Natacha Porté wrote: > Hello, > > on Thursday 07 June 2012 at 12:14, Richard Hipp wrote: > > On Thu, Jun 7, 2012 at 12:10 PM, Baptiste Daroussin < > > baptiste.darous...@gmail.com> wrote: > > > > > Is there any status on this? rejected ? still under review ? > > > > > > > DRH swamped. But it is on the list of potential changes for the Fossil > > Code Sprint in Munich on July 3! > > I was considering keeping the "markdown" branch in my public clone of > fossil by merging recent commits from trunk. Would it be useful or > harmful or irrelevant? > Useful. > > > > Natacha > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown engine integrated into fossil
Hello, on Thursday 07 June 2012 at 12:14, Richard Hipp wrote: > On Thu, Jun 7, 2012 at 12:10 PM, Baptiste Daroussin < > baptiste.darous...@gmail.com> wrote: > > > Is there any status on this? rejected ? still under review ? > > > > DRH swamped. But it is on the list of potential changes for the Fossil > Code Sprint in Munich on July 3! I was considering keeping the "markdown" branch in my public clone of fossil by merging recent commits from trunk. Would it be useful or harmful or irrelevant? Natacha pgp8HTZHJdYqk.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] Markdown engine integrated into fossil
On Thu, Jun 7, 2012 at 12:10 PM, Baptiste Daroussin < baptiste.darous...@gmail.com> wrote: > Is there any status on this? rejected ? still under review ? > DRH swamped. But it is on the list of potential changes for the Fossil Code Sprint in Munich on July 3! > > regards, > Bapt > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown engine integrated into fossil
Is there any status on this? rejected ? still under review ? regards, Bapt ___ 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] Markdown engine integrated into fossil
On 05/30/2012 02:28 PM, Natacha Porté wrote: > Hello, > > on Wednesday 23 May 2012 at 15:26, Richard Hipp wrote: >> Nevertheless, though attached by fraud, the name is still inappropriate, >> and must be changed before being added to Fossil. > Thanks to some invaluable help, I finally managed to get it done (I > think). > > My markdown C library shall henceforth be known as libsoldout. Name > chosen in the same theme as "markdown" and "discount", as one of the > possible aims (and the one I know best of) of real-life markdowns and > discounts, to make room for the new collection. Hey Natacha, Thanks so much for leading the fork of this project! I followed, with some dismay, the news when the whole project name thing blew up a few years ago. I hoped someone would just do the right thing (i.e. forking it, what you've done now) to put that kind of unpleasantness in its place. So I'm happy to see it's finally been done. Now, if only someone would do the same with the GIMP..;) Steve > The new repository is available at > http://fossil.instinctive.eu/libsoldout/home > and unless I misconfigured something, old links should be automatically > redirecting to valid equivalents in the new repository. > > As far as I know, all the unfortunate references have been purged from > the code. If there is any traces still lingering, please inform me and I > will deal with them as promptly as I can. > > I have not changed anything in the proposed integration into fossil > ( http://fossil.instinctive.eu/fossil-scm/timeline?r=markdown ) since > there was no reference whatsoever to the original project in the first > place. > > Known traces still lingering are: > > + the history of the project, but I'm strongly against rewriting > history in general, and I don't believe this case is extreme enough to > warrant a breach in the principle; > + the static archives of v1.1 of the library, linked from > http://fossil.instinctive.eu/ which will be replaced when I release v1.2 > (which has just entered beta), probably in one or two weeks; > + the reference to a fork in the home page, but since the it's the > name of the fork I have no control upon it. That fork should probably > not be mentioned at all, it will be removed in the next overhaul of the > page, leaving only a reference to sundown, probably within a few weeks too. > > I there anything else I should do? > > > Thanks for your attention, > Natacha Porté > > > ___ > 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] Markdown engine integrated into fossil
Hello, on Wednesday 23 May 2012 at 15:26, Richard Hipp wrote: > Nevertheless, though attached by fraud, the name is still inappropriate, > and must be changed before being added to Fossil. Thanks to some invaluable help, I finally managed to get it done (I think). My markdown C library shall henceforth be known as libsoldout. Name chosen in the same theme as "markdown" and "discount", as one of the possible aims (and the one I know best of) of real-life markdowns and discounts, to make room for the new collection. The new repository is available at http://fossil.instinctive.eu/libsoldout/home and unless I misconfigured something, old links should be automatically redirecting to valid equivalents in the new repository. As far as I know, all the unfortunate references have been purged from the code. If there is any traces still lingering, please inform me and I will deal with them as promptly as I can. I have not changed anything in the proposed integration into fossil ( http://fossil.instinctive.eu/fossil-scm/timeline?r=markdown ) since there was no reference whatsoever to the original project in the first place. Known traces still lingering are: + the history of the project, but I'm strongly against rewriting history in general, and I don't believe this case is extreme enough to warrant a breach in the principle; + the static archives of v1.1 of the library, linked from http://fossil.instinctive.eu/ which will be replaced when I release v1.2 (which has just entered beta), probably in one or two weeks; + the reference to a fork in the home page, but since the it's the name of the fork I have no control upon it. That fork should probably not be mentioned at all, it will be removed in the next overhaul of the page, leaving only a reference to sundown, probably within a few weeks too. I there anything else I should do? Thanks for your attention, Natacha Porté pgpYHrEpDb7eo.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] Markdown engine integrated into fossil
On Wed, May 30, 2012 at 1:24 PM, Ron Wilson wrote: > On Thu, May 24, 2012 at 1:51 AM, Natacha Porté wrote: >> >> If you don't mind, I'd rather have it not named at all. >> >> Due to how it's (still) heavily loaded with negative emotions, I would >> like not having to interact with the original project or its repository. >> And a name change at this level does involve quite a lot of interaction. > > In the open source community, people frequently start forks of other > projects and develop them independantly under new names. A recent > example of a high profile project is LibreOffice, which is a fork of > OpenOffice. > > Thank you for your good work. And sorry that you got caught up in this > controversy. You are in good company. History has many people who > created great works that had unfortunate names. (I decline to name any > as that is potentially another debate.) I also would like to thank Natacha for her great contribution and hope that as time goes by she might revisit her relationship with the original project. Unfortunately, human reaction to certain things like project naming could be unpredictable and sometimes destructive. Hopefully all the involved can get over it. --Leo-- ___ 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] Markdown engine integrated into fossil
On Thu, May 24, 2012 at 1:51 AM, Natacha Porté wrote: > > If you don't mind, I'd rather have it not named at all. > > Due to how it's (still) heavily loaded with negative emotions, I would > like not having to interact with the original project or its repository. > And a name change at this level does involve quite a lot of interaction. In the open source community, people frequently start forks of other projects and develop them independantly under new names. A recent example of a high profile project is LibreOffice, which is a fork of OpenOffice. Thank you for your good work. And sorry that you got caught up in this controversy. You are in good company. History has many people who created great works that had unfortunate names. (I decline to name any as that is potentially another debate.) ___ 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] Markdown engine integrated into fossil
on Wednesday 23 May 2012 at 15:26, Richard Hipp wrote: > Therefore, I hereby publicly apologize to Natasha for accusing her of > generating code that is less than beautiful, based solely on the name of > the code. The code is once again a candidate for incorporation into Fossil. Thanks. At this point I would like to say "apologies accepted", but I do not want it to sound like a reference to Star Wars, because I do mean it literally. > Nevertheless, though attached by fraud, the name is still inappropriate, > and must be changed before being added to Fossil. If you don't mind, I'd rather have it not named at all. Due to how it's (still) heavily loaded with negative emotions, I would like not having to interact with the original project or its repository. And a name change at this level does involve quite a lot of interaction. However the code I wrote for fossil is significantly different from the original, due to the integration of fossil idioms (and I'm willing to integrate even more, but further idioms would have to be pointed out to me since I couldn't find them by myself). By the way, you might not like the formatting of the C code, and that too I'm willing to change upon request. I thought it would be dishonest concealment to not mention even once the name of the original project, since that's where part of the code and all the design comes from. But I mentioned it only once. Just like the subject of this thread, the code only talks about a "markdown engine", without a name. Would the integration of such code, exactly like it is currently on my fossil clone, without any other reference to the original project than the first post of this thread, be acceptable? If it is not (for example if you really want references to the original project), then I'd rather we first address all technical issues, to ensure the code itself really has technical merit to be added, before proceeding to the painful renaming. Natacha Porté pgpdu022N7F8a.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] Markdown engine integrated into fossil
Richard, I really respect and appreciate your standards and the example you set. Also, I like the (almost always) kind way people treat each other on this list and you set the standard for that, as well. Thanks, Bill On Wed, May 23, 2012 at 2:26 PM, Richard Hipp wrote: > On Wed, May 23, 2012 at 1:31 PM, Baptiste Daroussin < > baptiste.darous...@gmail.com> wrote: > >> >> This is to bad that this great library is just pushed out because of >> an unfortunate name which was chosen for a joke (with references, that >> apparently noone from the native english speaking world get) and >> with out any perverse references in mind. >> > > I was initially dubious of this claim, due to fluent style of the author > Natasha writing. But further investigation, and references sent privately > to me by other on this list (thank you) suggest that I was wrong, and that > Natasha is in fact an innocent victim of fraud and that the name was > actually selected by mischievous (dare I say "perverted") third-party > native English-speaking male. > > Therefore, I hereby publicly apologize to Natasha for accusing her of > generating code that is less than beautiful, based solely on the name of > the code. The code is once again a candidate for incorporation into Fossil. > > Nevertheless, though attached by fraud, the name is still inappropriate, > and must be changed before being added to Fossil. > > > > -- > D. Richard Hipp > d...@sqlite.org > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > ___ 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] Markdown engine integrated into fossil
On Wed, May 23, 2012 at 1:31 PM, Baptiste Daroussin < baptiste.darous...@gmail.com> wrote: > > This is to bad that this great library is just pushed out because of > an unfortunate name which was chosen for a joke (with references, that > apparently noone from the native english speaking world get) and > with out any perverse references in mind. > I was initially dubious of this claim, due to fluent style of the author Natasha writing. But further investigation, and references sent privately to me by other on this list (thank you) suggest that I was wrong, and that Natasha is in fact an innocent victim of fraud and that the name was actually selected by mischievous (dare I say "perverted") third-party native English-speaking male. Therefore, I hereby publicly apologize to Natasha for accusing her of generating code that is less than beautiful, based solely on the name of the code. The code is once again a candidate for incorporation into Fossil. Nevertheless, though attached by fraud, the name is still inappropriate, and must be changed before being added to Fossil. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown engine integrated into fossil
> The choice of library name suggests that the author does not have a keen eye > for beauty, in which case the code is unlikely to be something I would care > to work with. Maybe the name of the library just don't represent the same for the author as for you, different culture, etc; but this really have nothing to do with having a keen eye for beauty. > Furthermore, I am disinclined to look at the code for fear of running across > comments that I would prefer not to read. You should really have a look at the code, it was written far before the name of the library, and there are no comments of any kind like you seem to imagine. This is to bad that this great library is just pushed out because of an unfortunate name which was chosen for a joke (with references, that apparently noone from the native english speaking world get) and with out any perverse references in mind. Please have a look at the code before judging of anything about the author, just judge the code and work she has done. You don't even have to name the library on the commit log, just "New markdown format support for embedded documentation or something like that". And if the name is a problem, I'm pretty sure she could easily be convinced to change the name of the library if someone come with a better name. Nothing in the code itself reference libupskirt regards, Bapt ___ 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] Markdown engine integrated into fossil
On Wed, May 23, 2012 at 1:00 PM, Stephan Beal wrote: > > FWIW, and in Natacha's defense: i'm a native US-English speaker, but i've > been away from the States long enough (going on 15 years) that "the U word" > entered my vocabulary for the first time today. It cannot be expected that > non-native speakers are always up-to-date on English slang. > My apologies if your conjecture is true, and the use of the term "upskirt" in the library name was innocent. Yet, while I am open to evidence to the contrary, I suspect that in this case the word was used with full knowledge of its connotations. But, maybe we could move past this and focus on technical matters? (And on creating *beautiful* software.) > > i vaguely remember Fossil's db file extension being changed from ".fos" to > something else at one point because "fos" is a non-polite word in Polish > (IIRC). > > The filename was changed ".fslckout" to avoid the word for a kind of body waste (the exact nature of which is still unknown to me) in Hungarian. The old name is still supported for legacy but is undocumented and deprecated. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown engine integrated into fossil
On Wed, May 23, 2012 at 6:39 PM, Richard Hipp wrote: > https://www.google.com/search?q=upskirt > http://en.wikipedia.org/wiki/Upskirt > FWIW, and in Natacha's defense: i'm a native US-English speaker, but i've been away from the States long enough (going on 15 years) that "the U word" entered my vocabulary for the first time today. It cannot be expected that non-native speakers are always up-to-date on English slang. i vaguely remember Fossil's db file extension being changed from ".fos" to something else at one point because "fos" is a non-polite word in Polish (IIRC). -- - 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] Markdown engine integrated into fossil
On Wed, May 23, 2012 at 12:41 PM, Weber, Martin S wrote: > > Not that bit. The bit about "even if you rename it to something that is > completely inoffensive, it will be difficult to rehabilitate the code". > Why is that? > The choice of library name suggests that the author does not have a keen eye for beauty, in which case the code is unlikely to be something I would care to work with. Furthermore, I am disinclined to look at the code for fear of running across comments that I would prefer not to read. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown engine integrated into fossil
On 2012-05-23 12:39 , "Richard Hipp" wrote: >On Wed, May 23, 2012 at 12:36 PM, Weber, Martin S > wrote: > >On 2012-05-23 12:18 , "Richard Hipp" wrote: >>Furthermore, even if you rename "libupskirt" to something that is >>completely benign and inoffensive, it will be difficult to rehabilitate >>the code. > >Do you mind explaining this bit please, Richard? >https://www.google.com/search?q=upskirt >http://en.wikipedia.org/wiki/Upskirt Not that bit. The bit about "even if you rename it to something that is completely inoffensive, it will be difficult to rehabilitate the code". Why is that? TIA, -Martin ___ 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] Markdown engine integrated into fossil
On Wed, May 23, 2012 at 12:36 PM, Weber, Martin S wrote: > On 2012-05-23 12:18 , "Richard Hipp" wrote: > >Furthermore, even if you rename "libupskirt" to something that is > >completely benign and inoffensive, it will be difficult to rehabilitate > >the code. > > Do you mind explaining this bit please, Richard? > https://www.google.com/search?q=upskirt http://en.wikipedia.org/wiki/Upskirt > > TIA, > -Martin > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown engine integrated into fossil
On 2012-05-23 12:18 , "Richard Hipp" wrote: >Furthermore, even if you rename "libupskirt" to something that is >completely benign and inoffensive, it will be difficult to rehabilitate >the code. Do you mind explaining this bit please, Richard? TIA, -Martin ___ 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] Markdown engine integrated into fossil
On Wed, May 23, 2012 at 12:25 PM, BohwaZ wrote: > Le Wed, 23 May 2012 12:18:52 -0400, Richard Hipp a > écrit : > > > We appreciate your efforts on behalf of Fossil. However, let me be > > very clear that any library with the name "libupskirt" has *zero* > > chance of ever getting official support or recognition from the > > Fossil project. Furthermore, even if you rename "libupskirt" to > > something that is completely benign and inoffensive, it will be > > difficult to rehabilitate the code. > > > > Note that after reading this far, and observing our choice of library > > names, I have chosen to read no further in your post. > > Did you even check her branch? There is no mention of libupskirt in the > code so far, so why the trolling on something irrelevant? > > Our goal is to create *beautiful* code. And there is nothing beautiful about voyeurism. Nor, I should add, is there anything beautiful about gratuitous profanity. Therefore, please mind your language on this list. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown engine integrated into fossil
On Wed, May 23, 2012 at 06:28:59PM +0200, Natacha Porté wrote: > on Wednesday 23 May 2012 at 12:18, Richard Hipp wrote: > > Note that after reading this far, and observing our choice of library > > names, I have chosen to read no further in your post. > > Oblivion was such a nice place for me to be... > > All by apologies for having dared creep out it. Natacha, thank you a lot for your work on fossil + markdown (and thank you for libupskirt). I also hold a modified version of fossil in a branch, where my changes did not please Richard; well, fossil is Richard's project, and it's up to him whether to accept some turns or others. And we can either keep a fork published or convince him to accept the changes; each option requires some work, and we have to balance. :) Richard, I hope you don't mind having the markdown code in a branch in the central repository. What do you think? On the other hand, I just looked for 'upskirt' on the dictionary and I had no idea on what it means. Maybe English people understand it just fine. But as someone already said in this thread, the libupskirt name does not appear in the fossil branch. Regards, Lluís. ___ 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] Markdown engine integrated into fossil
on Wednesday 23 May 2012 at 12:18, Richard Hipp wrote: > Note that after reading this far, and observing our choice of library > names, I have chosen to read no further in your post. Oblivion was such a nice place for me to be... All by apologies for having dared creep out it. pgp2vbVQ9SlGI.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] Markdown engine integrated into fossil
Le Wed, 23 May 2012 12:18:52 -0400, Richard Hipp a écrit : > We appreciate your efforts on behalf of Fossil. However, let me be > very clear that any library with the name "libupskirt" has *zero* > chance of ever getting official support or recognition from the > Fossil project. Furthermore, even if you rename "libupskirt" to > something that is completely benign and inoffensive, it will be > difficult to rehabilitate the code. > > Note that after reading this far, and observing our choice of library > names, I have chosen to read no further in your post. Did you even check her branch? There is no mention of libupskirt in the code so far, so why the hell trolling on something irrelevant? -- BohwaZ ___ 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] Markdown engine integrated into fossil
Le Wed, 23 May 2012 17:59:32 +0200, Stephan Beal a écrit : > While i don't personally care for markdown's syntax, i'd be all for > seeing this make its way into the trunk just so we can finally move > past The Wiki Wars ;). Why not, as long as we still can use the actual wiki syntax alongside the markdown syntax :) I'm just waiting for the usual and stupid troll about the lib name... -- BohwaZ ___ 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] Markdown engine integrated into fossil
On Wed, May 23, 2012 at 11:53 AM, Natacha Porté wrote: > Hello, > > stuff happens, and it turns out that now I have finished integrating my > markdown library (libupskirt) into fossil. We appreciate your efforts on behalf of Fossil. However, let me be very clear that any library with the name "libupskirt" has *zero* chance of ever getting official support or recognition from the Fossil project. Furthermore, even if you rename "libupskirt" to something that is completely benign and inoffensive, it will be difficult to rehabilitate the code. Note that after reading this far, and observing our choice of library names, I have chosen to read no further in your post. > And I really mean > "integrating", that is using struct Blob as dynamic buffers and other > idioms. > > I used it to translate *.mkd and *.markdown embedded docs in a similar > way as *.wiki are currently translated. > > The end result is available in the "markdown" branch at > http://fossil.instinctive.eu/fossil-scm/doc/trunk/www/index.wiki > > A demo repository using that extended fossil, with texts provided by > bapt, can be found at: > http://fossil.instinctive.eu/markdown-examples/doc/tip/README.mkd > http://fossil.instinctive.eu/markdown-examples/doc/tip/FAQ.mkd > > As far as I can tell through visual inspection, the markdown engine > passes the official markdown test suite. I don't publish the result > becasue I haven't found any licence for the test suite, so I guess > redistributing it is illegal. > > The current implementation supports only vanilla markdown along with > talbe (using PHP-Markdown-Extra syntax). Quite a few other extensions > can be easily added, just like they were in libupskirt, and I'm willing > to add them (or remove the table extension) if a consensus can be > reached on a particular set of extensions. > > I would gladly welcome any bug report, code review or otherwise > constructive criticism. > > > Hoping this helps, > Natacha Porté > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown engine integrated into fossil
On Wed, May 23, 2012 at 5:53 PM, Natacha Porté wrote: > I used it to translate *.mkd and *.markdown embedded docs in a similar > way as *.wiki are currently translated. > FWIW (not that my opinion really matters)... The addition of a more common wiki parser into fossil has arguably been the most-requested feature the past 4+ years i've been hanging around on this list. Everyone has their favourite/least favourite wiki format, but it seems to me (based largely on the many threads on this topic) that Markdown is the best-liked of the wiki formats (at least amongst the hacking community). While i don't personally care for markdown's syntax, i'd be all for seeing this make its way into the trunk just so we can finally move past The Wiki Wars ;). 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
