Discussion:
The future of markdown-in-fossil
(too old to reply)
Natacha Porté
2012-07-30 08:41:25 UTC
Permalink
Hello,

I don't want to look impatient, and I personally hate to be constantly
reminded about something that hasn't actually left my mind, so I'm a bit
reluctant to send e-mails like this one. All my apologies if I'm doing
it wrong.

So my point is only to remind you all that I'm still committed to make
the fossil-in-markdown thing going forward, and I'm eagerly waiting any
instructions on what to do about it next.

Currently the code is in a new branch off a clone of the official fossil
repository, available at
http://fossil.instinctive.eu/fossil-scm/timeline?r=markdown

There is also a live demo (dedicated repository served using a fossil
compiled off this branch) at
http://fossil.instinctive.eu/markdown-examples/doc/tip/README.mkd

What is done:
+ complete and seamless integration of the markdown engine into fossil
(e.g. using fossil blobs as dynamic buffers),
+ support of markdown embedded documentation (.markdown and .mkd
extensions), using current fossil style,
+ regular merge of latest changes from trunk.

What remains to do:
+ review my code to ensure it meets fossil level of quality,
+ format it using fossil code style if needed,
+ any other code change that comes up during the review.

I'm still willing to perform any maintenance needed on the markdown
library code and/or the glue between it and fossil, for as long as I
can. I would also gladly handle any knowledge-transfer needed to prevent
myself from being a single point of failure in the maintenance of that
code.



Thanks for your interest,
Natacha Porté
Stephan Beal
2012-07-30 16:53:05 UTC
Permalink
Post by Natacha Porté
+ review my code to ensure it meets fossil level of quality,
+ format it using fossil code style if needed,
+ any other code change that comes up during the review.
i will be happy to offer my 0.0163 Euros, but i won't be able to do so
until later in the week. Richard is, from what i understand, swamped for
the foreseeable future. Of course, anyone else is encouraged to help :).
While i don't personally use MD i'd like to see it added if only because
people keep asking about it ;). Maybe then some of the religious wars can
end ;).

i will post back once i have looked over it. Would you prefer that i send
comments regarding it to the list or to you directly?


Thanks for your interest,
And thank you for your contribution and persistence.

To be clear: the final decision about what goes in to the trunk belongs to
Richard and Richard alone. The other contributors, such as a myself, are
here to assist, but the final decision rests with him. For what i'd worth,
i'd like to see it included (but would like to look at the code first ;).

Happy Hacking!
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Bill Burdick
2012-07-30 17:38:08 UTC
Permalink
I'd like to see it included, as well!
Post by Stephan Beal
Post by Natacha Porté
+ review my code to ensure it meets fossil level of quality,
+ format it using fossil code style if needed,
+ any other code change that comes up during the review.
i will be happy to offer my 0.0163 Euros, but i won't be able to do so
until later in the week. Richard is, from what i understand, swamped for
the foreseeable future. Of course, anyone else is encouraged to help :).
While i don't personally use MD i'd like to see it added if only because
people keep asking about it ;). Maybe then some of the religious wars can
end ;).
i will post back once i have looked over it. Would you prefer that i send
comments regarding it to the list or to you directly?
Thanks for your interest,
And thank you for your contribution and persistence.
To be clear: the final decision about what goes in to the trunk belongs to
Richard and Richard alone. The other contributors, such as a myself, are
here to assist, but the final decision rests with him. For what i'd worth,
i'd like to see it included (but would like to look at the code first ;).
Happy Hacking!
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Gautier DI FOLCO
2012-07-30 17:43:25 UTC
Permalink
Post by Bill Burdick
I'd like to see it included, as well!
I'd like it too, it will be easier for beginnes (like me!).
Remigiusz Modrzejewski
2012-08-03 09:23:51 UTC
Permalink
Post by Gautier DI FOLCO
Post by Bill Burdick
I'd like to see it included, as well!
I'd like it too, it will be easier for beginnes (like me!).
+1

Kind regards,
Remigiusz Modrzejewski
Michal Suchanek
2012-08-03 09:53:27 UTC
Permalink
Post by Gautier DI FOLCO
Post by Bill Burdick
I'd like to see it included, as well!
I'd like it too, it will be easier for beginnes (like me!).
+1
Why markdown and not one of the dozens of other wiki syntaxes?

I don't find wiki syntaxes really easy. Maybe a bit easier to type
than HTML but definitely not easy to read or remember, especially
since there are dozens of slightly (and not so slightly) different
variants.

Note there are JavaScript hacks for interpreting random wiki syntax so
you can have markdown interpreted without any direct support in
fossil.

Thanks

Michal
Remigiusz Modrzejewski
2012-08-03 10:07:40 UTC
Permalink
Post by Michal Suchanek
+1
Why markdown and not one of the dozens of other wiki syntaxes?
Because markdown is a very popular one, used by github, and we have on board the creator of a major implementation (the one used by github, iirc).
Post by Michal Suchanek
I don't find wiki syntaxes really easy. Maybe a bit easier to type
than HTML but definitely not easy to read or remember, especially
since there are dozens of slightly (and not so slightly) different
variants.
That's why half of the web seems to standarize on markdown. The same web that was mostly writing HTML a few years ago.
Post by Michal Suchanek
Note there are JavaScript hacks for interpreting random wiki syntax so
you can have markdown interpreted without any direct support in
fossil.
Note there are good wiki engines out there, so no need for one in Fossil too. But once we set the scope to include something, please don't keep it half-hearted...


Kind regards,
Remigiusz Modrzejewski
Michal Suchanek
2012-08-03 10:19:01 UTC
Permalink
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
+1
Why markdown and not one of the dozens of other wiki syntaxes?
Because markdown is a very popular one, used by github, and we have on board the creator of a major implementation (the one used by github, iirc).
The others are also very popular.

Github has a cute logo but I would not turn to it when looking for
sound technical solutions.
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
I don't find wiki syntaxes really easy. Maybe a bit easier to type
than HTML but definitely not easy to read or remember, especially
since there are dozens of slightly (and not so slightly) different
variants.
That's why half of the web seems to standarize on markdown. The same web that was mostly writing HTML a few years ago.
Does not seem that way to me.

I deal with sites using various wiki format variations.

If you want to make your point on that then supply more data, please.
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
Note there are JavaScript hacks for interpreting random wiki syntax so
you can have markdown interpreted without any direct support in
fossil.
Note there are good wiki engines out there, so no need for one in Fossil too. But once we set the scope to include something, please don't keep it half-hearted...
And it has been said that markdown is out of the scope of Fossil. I am
not to decide that but I have to agree. Once you let in markdown
people used to some other wiki syntax would argue they have needlessly
hard time and there would be no end to the stream of requests to
include yet another.

Thanks

Michal
Remigiusz Modrzejewski
2012-08-03 10:26:27 UTC
Permalink
Post by Michal Suchanek
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
Why markdown and not one of the dozens of other wiki syntaxes?
Because markdown is a very popular one, used by github, and we have on board the creator of a major implementation (the one used by github, iirc).
Github has a cute logo but I would not turn to it when looking for
sound technical solutions.
Still, somehow, they don't seem a failure. A cute logo can't buy that...
Post by Michal Suchanek
Post by Remigiusz Modrzejewski
That's why half of the web seems to standarize on markdown. The same web that was mostly writing HTML a few years ago.
Does not seem that way to me.
I deal with sites using various wiki format variations.
If you want to make your point on that then supply more data, please.
No data. Just the anecdotal: a few years ago most input fields I've hit on the web accepted sanitized HTML, now they take markdown. Yeah, they're usually not wikis (but the wiki engine I use actually uses markdown).
Post by Michal Suchanek
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
Note there are JavaScript hacks for interpreting random wiki syntax so
you can have markdown interpreted without any direct support in
fossil.
Note there are good wiki engines out there, so no need for one in Fossil too. But once we set the scope to include something, please don't keep it half-hearted...
And it has been said that markdown is out of the scope of Fossil. I am
not to decide that but I have to agree. Once you let in markdown
people used to some other wiki syntax would argue they have needlessly
hard time and there would be no end to the stream of requests to
include yet another.
I've read the "we'll have requests for all the markups in the world" argument many times. I can't remember anyone actually coming and asking for *anything* else than markdown.


Kind regards,
Remigiusz Modrzejewski
Michal Suchanek
2012-08-03 10:31:24 UTC
Permalink
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
Note there are JavaScript hacks for interpreting random wiki syntax so
you can have markdown interpreted without any direct support in
fossil.
Note there are good wiki engines out there, so no need for one in Fossil too. But once we set the scope to include something, please don't keep it half-hearted...
And it has been said that markdown is out of the scope of Fossil. I am
not to decide that but I have to agree. Once you let in markdown
people used to some other wiki syntax would argue they have needlessly
hard time and there would be no end to the stream of requests to
include yet another.
I've read the "we'll have requests for all the markups in the world" argument many times. I can't remember anyone actually coming and asking for *anything* else than markdown.
That may also prove only that markdown proponents are noisy and inconsiderate.

Project X should have markdown because it is what I am familiar with
and it seems to me the best and most widespread syntax, meh.

Regards

Michal
Richie Adler
2012-08-03 17:00:56 UTC
Permalink
Remigiusz Modrzejewski decía, en el mensaje "Re: [fossil-users] The future of
Post by Remigiusz Modrzejewski
I've read the "we'll have requests for all the markups in the world"
argument many times. I can't remember anyone actually coming and asking for
*anything* else than markdown.
I was going to wait until the whole Markup brouhaha was ended, but I for one
would like support for reStructuredText :)
--
o-=< Marcelo >=-o
Natacha Porté
2012-08-03 11:04:34 UTC
Permalink
Hello,
Post by Michal Suchanek
Post by Michal Suchanek
Why markdown and not one of the dozens of other wiki syntaxes?
If I understand correctly this question wasn't addressed to me (as a
developer of the markdown-in-fossil code) but I'll try to contribute as
objectively as I can.

As a user, the killer feature I see for markdown is that the
implementation exists (assuming my code is considered worthy, which is
quite a strong assumption, but without it everything else is moot
anyway, so I'll keep the assumption in this e-mail). Code that exists
wins over code that does not. We can discuss for days about the best
markup syntax, it's completely useless when there is nobody to actually
implement it.

Of course, I would welcome other propositions of implementation, and I
would still be glad if my code was rejected in favor of another
implementation (of markdown or of another lightweight markup language
that I prefer to the current wiki syntax).

Now my personal opinion about markdown is probably of no interest to
anybody else, but while I do have strong objections and dislikings
about it, I haven't encountered any other lightweight markup syntax with
which I have more affinity. Useless, isn't it?
Post by Michal Suchanek
And it has been said that markdown is out of the scope of Fossil.
I don't know about that. And honestly, I'm glad I don't have to make
that call.
Post by Michal Suchanek
I am
not to decide that but I have to agree. Once you let in markdown
people used to some other wiki syntax would argue they have needlessly
hard time and there would be no end to the stream of requests to
include yet another.
I think it's very useful to distinguish between requests to write code in
order to include yet another, and requests to officially mirror a branch
containing ready-to-use code that includes yet another.

Surely the stream of the second kind of requests would be much lighter
than the stream of the first kind, wouldn't it?

And as far as requests of the second kind goes, if the code is good
enough and does not bloat the project, why not accept them? (in the
context that assumes markdown has already been let in)



Thanks for your criticism,
Natacha Porté
Michal Suchanek
2012-08-03 11:41:38 UTC
Permalink
Post by Natacha Porté
Hello,
Post by Michal Suchanek
Post by Michal Suchanek
Why markdown and not one of the dozens of other wiki syntaxes?
If I understand correctly this question wasn't addressed to me (as a
developer of the markdown-in-fossil code) but I'll try to contribute as
objectively as I can.
As a user, the killer feature I see for markdown is that the
implementation exists (assuming my code is considered worthy, which is
quite a strong assumption, but without it everything else is moot
anyway, so I'll keep the assumption in this e-mail). Code that exists
wins over code that does not. We can discuss for days about the best
markup syntax, it's completely useless when there is nobody to actually
implement it.
By the extension of this very argument, code that exists in-tree beats
code that exists out of tree. So the current syntax wins.
Post by Natacha Porté
Of course, I would welcome other propositions of implementation, and I
would still be glad if my code was rejected in favor of another
implementation (of markdown or of another lightweight markup language
that I prefer to the current wiki syntax).
Now my personal opinion about markdown is probably of no interest to
anybody else, but while I do have strong objections and dislikings
about it, I haven't encountered any other lightweight markup syntax with
which I have more affinity. Useless, isn't it?
I have strong objections about all such makups, none is perfect, all
have some annoyances, and they are all mutually incompatible.

Changing from one to another does not improve things, however. It only
brings incompatible repositories into existence.

I have looked up the markdown syntax on wikipedia and while it removes
some annoyances of the more traditional wiki syntaxes like moinmoin or
mediawiki it can do that only at the cost of mutual incompatibility.

Interestingly, being a github user I am not familiar with the markdown
syntax although github supposedly uses it. Admittedly I have used more
moinmoin wikis, mediawikis, and phpbbs than githubs, both in total and
each separately.

Consider bbcode, too. It is not only familiar to developers but it is
even more ancient and more widespread than any wiki syntax, and many
non-developers use it.

And all of these markups are mutually incompatible. Unless you are
willing to implement a plugin engine with plugins for 3-4 most
widespread markups there is no way to really improve over what there
is now. You will also have to change the format of the database so
that it contains an additional field for text artifacts like tickets
so that they can be rendered with the correct plugin.
Post by Natacha Porté
Post by Michal Suchanek
And it has been said that markdown is out of the scope of Fossil.
I don't know about that. And honestly, I'm glad I don't have to make
that call.
Post by Michal Suchanek
I am
not to decide that but I have to agree. Once you let in markdown
people used to some other wiki syntax would argue they have needlessly
hard time and there would be no end to the stream of requests to
include yet another.
I think it's very useful to distinguish between requests to write code in
order to include yet another, and requests to officially mirror a branch
containing ready-to-use code that includes yet another.
Surely the stream of the second kind of requests would be much lighter
than the stream of the first kind, wouldn't it?
And as far as requests of the second kind goes, if the code is good
enough and does not bloat the project, why not accept them? (in the
context that assumes markdown has already been let in)
Because of compatibility with existing repositories that use the
current syntax which is not compatible with markdown.

As you did not include a link to your repository of markdown enabled
fossil I cannot tell how it addresses compatibility.

Thanks

Michal
Natacha Porté
2012-08-03 12:02:38 UTC
Permalink
Hello,
Post by Michal Suchanek
Post by Natacha Porté
As a user, the killer feature I see for markdown is that the
implementation exists (assuming my code is considered worthy, which is
quite a strong assumption, but without it everything else is moot
anyway, so I'll keep the assumption in this e-mail). Code that exists
wins over code that does not. We can discuss for days about the best
markup syntax, it's completely useless when there is nobody to actually
implement it.
By the extension of this very argument, code that exists in-tree beats
code that exists out of tree. So the current syntax wins.
Indeed. And that's the only reason I've ever used it.

But now, on the binaries I use, both exist. So as far as I'm concerned,
they are both as accessible, and the tie is broken by my preference on
Markdown. And the only reason I'm posting to this list is to propose
such a situation to anyone interested.
Post by Michal Suchanek
I have strong objections about all such makups, none is perfect, all
have some annoyances, and they are all mutually incompatible.
Changing from one to another does not improve things, however. It only
brings incompatible repositories into existence.
You're going much further than I am here. What I have proposed does not
introduce any incompatibility at all. I have only included the markdown
engine and used it for inline ("embedded doc") rendering of .mkd and
.markdown files in the repository.

As I have said elsewhere, I'm not clever enough to imagine a solution to
introduce markdown into fossil's internal wiki. So I don't propose it. I
propose the extra embedded doc rendering, and the tools to perform any
markdown-to-html conversion. When someone comes up with a way to deal
with the internal wiki, they will have such tools.
Post by Michal Suchanek
Post by Natacha Porté
Post by Michal Suchanek
I am
not to decide that but I have to agree. Once you let in markdown
people used to some other wiki syntax would argue they have needlessly
hard time and there would be no end to the stream of requests to
include yet another.
I think it's very useful to distinguish between requests to write code in
order to include yet another, and requests to officially mirror a branch
containing ready-to-use code that includes yet another.
Surely the stream of the second kind of requests would be much lighter
than the stream of the first kind, wouldn't it?
And as far as requests of the second kind goes, if the code is good
enough and does not bloat the project, why not accept them? (in the
context that assumes markdown has already been let in)
Because of compatibility with existing repositories that use the
current syntax which is not compatible with markdown.
Well remember that I assumed markdown already in, and therefore this
objection already correctly addressed. So that does not qualifies as a
reason to not accept further code.
Post by Michal Suchanek
As you did not include a link to your repository of markdown enabled
fossil I cannot tell how it addresses compatibility.
I did. In the very first post of this thread.



Natacha Porté
Michal Suchanek
2012-08-03 12:56:55 UTC
Permalink
Post by Natacha Porté
Hello,
Post by Michal Suchanek
I have strong objections about all such makups, none is perfect, all
have some annoyances, and they are all mutually incompatible.
Changing from one to another does not improve things, however. It only
brings incompatible repositories into existence.
You're going much further than I am here. What I have proposed does not
introduce any incompatibility at all. I have only included the markdown
engine and used it for inline ("embedded doc") rendering of .mkd and
.markdown files in the repository.
As I have said elsewhere, I'm not clever enough to imagine a solution to
introduce markdown into fossil's internal wiki. So I don't propose it. I
propose the extra embedded doc rendering, and the tools to perform any
markdown-to-html conversion. When someone comes up with a way to deal
with the internal wiki, they will have such tools.
Well, then it is less than satisfactory solution.

HTML is formatted in the browser. Hence support for HTML documents
comes for free, with no code required. It is passed through as any
other file type.

The fossil wiki syntax is used in tickets and internal wiki anyway so
documents in that syntax come nearly for free. The only concern is
proper hyperlink resolution so that you can browse the site. Users
need to know the format for the tickets and internal wiki anyway, and
you have cut&paste between docs and and wiki and tickets.

Now enter .mkd files. They need additional code to parse, there is no
such nice integration with the rest of the fossil, and they do not
solve the issue of "I am not familiar with this" for the users
familiar with the other formats.

And given somebody wrote a bbcode parser implementation, moin moin
parser implementation, and a half dozen others which will be allowed
in the fossil proper? Or is parser for any random format to be added?
How large will fossil then become? Who will maintain all this? Is the
parser to be removed again when the original author is no longer
interested and no other maintainer for it steps up?
Post by Natacha Porté
Post by Michal Suchanek
As you did not include a link to your repository of markdown enabled
fossil I cannot tell how it addresses compatibility.
I did. In the very first post of this thread.
Sorry, only saw some replies, not the starting post.

Thanks

Michal
Stephan Beal
2012-08-03 13:00:14 UTC
Permalink
Post by Michal Suchanek
And given somebody wrote a bbcode parser implementation, moin moin
parser implementation, and a half dozen others which will be allowed
in the fossil proper? Or is parser for any random format to be added?
And now i KNOW you missed the previous thousand threads ;). No other impls
have been added, largely for the reasons you suggest: maintenance, bloat,
and general acceptance. MD, however, seems to have had the most/loudest
proponents the past few years.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Konstantin Khomoutov
2012-08-03 13:37:32 UTC
Permalink
On Fri, 3 Aug 2012 14:02:38 +0200
Natacha Porté <***@instinctive.eu> wrote:

[...]
Post by Natacha Porté
As I have said elsewhere, I'm not clever enough to imagine a solution
to introduce markdown into fossil's internal wiki. So I don't propose
it. I propose the extra embedded doc rendering, and the tools to
perform any markdown-to-html conversion. When someone comes up with a
way to deal with the internal wiki, they will have such tools.
Ikiwiki allows to use several different markup engines for its pages
(markdown is builtin, others can be installed in the form of plugins),
and it allows the author to pick the markup engine for the page at the
time the page is created (see the attached image).

The type of markup syntax selected for the page is then codified in the
extension of the file which is created by the wiki engine for that page.

Supposedly, Fossil's wiki page editor could provide the same pick list
the first time a page is created and then persist the chosen markup
syntax with the page entry itself in an appropriate table.

Is that possible?

[...]
Stephan Beal
2012-08-03 13:47:10 UTC
Permalink
On Fri, Aug 3, 2012 at 3:37 PM, Konstantin Khomoutov <
Post by Konstantin Khomoutov
Supposedly, Fossil's wiki page editor could provide the same pick list
the first time a page is created and then persist the chosen markup
syntax with the page entry itself in an appropriate table.
Is that possible?
(Restricting myself to client-side for the moment...)

In fact... the direct forefather of fossil's JSON wiki API demonstrates
doing exactly this:

http://whiki.wanderinghorse.net/?page=whiki

These pages show 3 page-specified renderers in action (it uses a
name-extension mapper):
http://whiki.wanderinghorse.net/?page=fossil2whiki.sh
http://whiki.wanderinghorse.net/?page=MarkDownTest
http://whiki.wanderinghorse.net/?page=README.txt

JSON API derives directly from whiki (which was originally written to
replace fossil's wiki for some of my projects, so that code ended up coming
full-circle), and i see no reason this cannot be done with fossil's json
wiki API as well.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Stephan Beal
2012-08-03 13:48:14 UTC
Permalink
Post by Stephan Beal
These pages show 3 page-specified renderers in action (it uses a
That's a lie - each page has a client-specified mime-type string. Click on
the editor button on these pages to see that.
Post by Stephan Beal
http://whiki.wanderinghorse.net/?page=fossil2whiki.sh
http://whiki.wanderinghorse.net/?page=MarkDownTest
http://whiki.wanderinghorse.net/?page=README.txt
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Konstantin Khomoutov
2012-08-03 12:40:10 UTC
Permalink
On Fri, 3 Aug 2012 12:19:01 +0200
Post by Michal Suchanek
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
Why markdown and not one of the dozens of other wiki syntaxes?
Because markdown is a very popular one, used by github, and we have
on board the creator of a major implementation (the one used by
github, iirc).
The others are also very popular.
Github has a cute logo but I would not turn to it when looking for
sound technical solutions.
Stackoverflow and all the sites under its umbrella, and all the sites
using this engine, use (modified) markdown syntax [1], [2].

I, for one, while not being a special fan of markdown syntax (to me, the
best sytnax I ever had to deal with was that used by wiki.tcl.tk), still
think that the proliferation of wiki markups place everyone in position
where one just can pick a syntax to use almost at random.
Markdown is a) popular; b) has a (seemingly) sound C library
implementation. Hence to me it looks like a perfect choice for a
project like Fossil.

[...]

1. http://blog.stackoverflow.com/2009/10/markdown-one-year-later/
2. http://stackoverflow.com/editing-help/
Michal Suchanek
2012-08-03 13:06:45 UTC
Permalink
On 3 August 2012 14:40, Konstantin Khomoutov
Post by Konstantin Khomoutov
On Fri, 3 Aug 2012 12:19:01 +0200
Post by Michal Suchanek
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
Why markdown and not one of the dozens of other wiki syntaxes?
Because markdown is a very popular one, used by github, and we have
on board the creator of a major implementation (the one used by
github, iirc).
The others are also very popular.
Github has a cute logo but I would not turn to it when looking for
sound technical solutions.
Stackoverflow and all the sites under its umbrella, and all the sites
using this engine, use (modified) markdown syntax [1], [2].
So again a somewhat slightly incompatible variation.

And there are many using moinmoin or similar syntax, and many using
bbcode, and there are probably others in wide use already.
Post by Konstantin Khomoutov
I, for one, while not being a special fan of markdown syntax (to me, the
best sytnax I ever had to deal with was that used by wiki.tcl.tk), still
think that the proliferation of wiki markups place everyone in position
where one just can pick a syntax to use almost at random.
And for fossil it has been picked already.

Thanks

Michal
Konstantin Khomoutov
2012-08-03 13:31:55 UTC
Permalink
On Fri, 3 Aug 2012 15:06:45 +0200
Michal Suchanek <***@gmail.com> wrote:

[...]
Post by Michal Suchanek
Post by Konstantin Khomoutov
Stackoverflow and all the sites under its umbrella, and all the
sites using this engine, use (modified) markdown syntax [1], [2].
So again a somewhat slightly incompatible variation.
Correct, but I hardly perceive this as being an issue.

[...]
Post by Michal Suchanek
Post by Konstantin Khomoutov
I, for one, while not being a special fan of markdown syntax (to
me, the best sytnax I ever had to deal with was that used by
wiki.tcl.tk), still think that the proliferation of wiki markups
place everyone in position where one just can pick a syntax to use
almost at random.
And for fossil it has been picked already.
The idea behind pushing Markdown (or whatever else) engine to Fossil
is providing a *rich* set of markup capabilities. The problem with
builtin Fossil markup engine is that its too simplistic to be usable.
In fact, it's usable for one-line pages, but as soon as you want to
roll something a bit more complicated (itemized/numerated lists being
the first feature I need) you bump to the need of writing HTML, with no
support from the UI to do so.
I do understand the rationale for this approach; if I were the author
of Fossil (I'm incapable for this, but let's pretend I am, for the
moment) I'd probably pick the same approach during an early phase of
development. Now it seems that quite many users see overly simple
markup capabilities of the Fossil's wiki engine to be a problem; a
soultion exists and is even integrated.
Stephan Beal
2012-08-03 13:42:05 UTC
Permalink
On Fri, Aug 3, 2012 at 3:31 PM, Konstantin Khomoutov <
Post by Konstantin Khomoutov
I do understand the rationale for this approach; if I were the author
of Fossil (I'm incapable for this, but let's pretend I am, for the
moment) I'd probably pick the same approach during an early phase of
development. Now it seems that quite many users see overly simple
markup capabilities of the Fossil's wiki engine to be a problem; a
soultion exists and is even integrated.
Another consideration here is that the wiki has kind of fallen out of use,
with the embedded docs system generally being preferred. While i admit that
i pay a good deal of attention to fossil's wiki API (i've added several of
the wiki subcommands and the wiki API was amongst the first of the JSON
APIs added), i will admit that embedded docs are generally a better
solution. But the wiki is just too convenient (which is the only reason
anyone really uses a wiki, anyway). Once i get embedded docs support in the
JSON API, i probably won't touch the wiki API again.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Konstantin Khomoutov
2012-08-03 14:27:50 UTC
Permalink
On Fri, 3 Aug 2012 15:42:05 +0200
Post by Stephan Beal
Post by Konstantin Khomoutov
I do understand the rationale for this approach; if I were the
author of Fossil (I'm incapable for this, but let's pretend I am,
for the moment) I'd probably pick the same approach during an early
phase of development. Now it seems that quite many users see
overly simple markup capabilities of the Fossil's wiki engine to be
a problem; a soultion exists and is even integrated.
Another consideration here is that the wiki has kind of fallen out of
use, with the embedded docs system generally being preferred. While i
admit that i pay a good deal of attention to fossil's wiki API (i've
added several of the wiki subcommands and the wiki API was amongst
the first of the JSON APIs added), i will admit that embedded docs
are generally a better solution. But the wiki is just too convenient
(which is the only reason anyone really uses a wiki, anyway). Once i
get embedded docs support in the JSON API, i probably won't touch the
wiki API again.
My personal use case for Fossil's intergated wiki is a structured place
to perform "brain dumps": that is, I have a problem to solve (and I'm
writing code which is to solve it, hosting it using Fossil), and start
to write down my observations on how to attack different parts of it,
findings on the nature of the data I had to process etc. This fits the
wiki paradigm rather well and does not really fit to the domain of the
built-in documentation. Unfortunately, in my case I did have the need
to use nested lists, convenient ways to insert multiline verbatim bits
of text, and I'd love to have some (basic) support for tables (what
ikiwiki has [1] would be just enough).

Uploading images and inserting wiki links to them would also be a win
for me (again, ikiwiki provides for this; this is called "attachments"
in its lingo [2]). This would probably be an overkill for a markup
engine built into Fossil, but I found myself wanting this feature more
than once.
Yeah, every time I think about this I do understand I could just
create a page in my intranet ikiwiki instance an link to it from my
Fossil's project's wiki page, but this kind of questions the whole
point of having a built-in wiki engine. ;-)

P.S.
I'm constantly referring to ikiwiki because it stores all its content
in a [D]VCS (Git in my particular case), and so does Fossil with its
wiki engine.

1. http://ikiwiki.info/ikiwiki/directive/table/
2. http://ikiwiki.info/plugins/attachment/
Joan Picanyol i Puig
2012-08-04 11:22:17 UTC
Permalink
Post by Stephan Beal
Another consideration here is that the wiki has kind of fallen out of use,
with the embedded docs system generally being preferred. While i admit that
i pay a good deal of attention to fossil's wiki API (i've added several of
the wiki subcommands and the wiki API was amongst the first of the JSON
APIs added), i will admit that embedded docs are generally a better
solution. But the wiki is just too convenient (which is the only reason
anyone really uses a wiki, anyway). Once i get embedded docs support in the
JSON API, i probably won't touch the wiki API again.
I believe you are underestimating the built-in wiki. As I see it is one
of fossil's killer features: my use case is a dramatically lower barrier
to entry for non-developers contributing to a non-distributed repo.

qvb
--
pica
Stephan Beal
2012-08-04 11:32:21 UTC
Permalink
Post by Joan Picanyol i Puig
I believe you are underestimating the built-in wiki. As I see it is one
of fossil's killer features: my use case is a dramatically lower barrier
to entry for non-developers contributing to a non-distributed repo.
In fact the wiki and CGI support were what got me so interested in the
first place. i still use the wiki, but for longer-term doc management the
embedded docs provide better support (e.g. the ability to edit/preview them
using /doc/ckout/..., plus full versioning and branching).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Jan Danielsson
2012-08-06 09:46:58 UTC
Permalink
On 08/03/12 15:42, Stephan Beal wrote:
[---]
Post by Stephan Beal
Another consideration here is that the wiki has kind of fallen out of use,
[---]

I don't know that that is true. The only proof of this I have seen
prior to this thread is that at times it's mentioned that the fossil
repository uses embedded wiki rather than the "built in" wiki.

For my part, I use the "built in" editor/wiki command line on a daily
basis, and it would sadden me greatly if it is depreciated, or if
someone would scrap any ideas of enhancements to it due to the perceived
notion that no one uses it any more. ...that said, I realize I could be
the only one still using it. :)

The embedded wiki is useful for pages which are versioned. But there
are lots of things which I write which principally aren't meant to be
"versioned", such as wide-perspective project goals, code conventions,
security considerations, protocol requirements, etc. Things which are
true in the past, present and future. I also have a central repository
on a server which serves as "reference pages" (I collect notes on
administration of things I very rarely do, cool/useful shell tricks,
etc), and it would be too much hassle to use the embedded wiki system
for that.

While I'm anyways on the topic of things which worry me a little..

I travel by train a lot, and on the train I don't always have access
to an electrical socket, so I run the laptop on battery. For this reason
I often run without X (I want as good battery time as possible). Now, I
don't want to come off as one of those "got off my lawn, you kids!"
types, so I'll be very explicit: I'm 100% for all the AJAX:ish work
being done and considered. It adds a lot of value to the users
(including myself), so it should be there and continue to be worked on.

That being said, I want to (as far as possible) be able to do what I
do with fossil at home even when I'm working on the train, in console
mode. This is the primary reason I would want markdown support (in the
built-in wiki and ticket system): I think it's easier to read/parse
(mentally) and write than any wiki syntax I've seen so far. And even if
we get a nice WYSIWYG editor for the web interface (in theory rendering
the stored format irrelevant), I'll still be sitting writing wiki
documents on the train in plain old vim, because there really isn't any
other option.
--
Kind regards,
Jan Danielsson
Stephan Beal
2012-08-06 15:07:19 UTC
Permalink
On Mon, Aug 6, 2012 at 11:46 AM, Jan Danielsson
Post by Jan Danielsson
For my part, I use the "built in" editor/wiki command line on a daily
basis, and it would sadden me greatly if it is depreciated, or if
someone would scrap any ideas of enhancements to it due to the perceived
notion that no one uses it any more. ...that said, I realize I could be
the only one still using it. :)
Sorry, i didn't mean to imply that it was being deprecated. It is one of
fossil's core features, and it DOES get used by many people, but not so
much in the fossil project itself. (In fact, the wiki and CGI is what
originally caught my eye in fossil.)
Post by Jan Danielsson
The embedded wiki is useful for pages which are versioned. But there
are lots of things which I write which principally aren't meant to be
...etc), and it would be too much hassle to use the embedded wiki system
for that.
It's certainly more convenient for that type of thing.
Post by Jan Danielsson
While I'm anyways on the topic of things which worry me a little..
No worries - wiki is there to stay. Even if we wanted to (which we don't!),
removing it would be a huge compatibility problem and would upset probably
30-50% of the users pretty badly ;).
Post by Jan Danielsson
That being said, I want to (as far as possible) be able to do what I
do with fossil at home even when I'm working on the train, in console
mode.
fossil wiki export ...
fossil wiki commit ...
Post by Jan Danielsson
we get a nice WYSIWYG editor for the web interface (in theory rendering
the stored format irrelevant), I'll still be sitting writing wiki
documents on the train in plain old vim, because there really isn't any
other option.
We DO have a wysiwyg editor on the list of todos, but it is pending the
"custom pages" support because that support will include the infrastructure
we need for serving the editor. i've been tinkering with the custom
pages/commands support for 3-4 weeks now, but with my current approach
(based on TH1) i keep running into a wall regarding what types of things we
can reasonably do with th1. Over the weekend i had a nice chat with Joe
Mistachkin about TCL, and i think the only reasonable way to do custom
pages/commands (that is, without having to castrate them unduly) is to use
his TCL support. Anwyay...
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Alaric Snell-Pym
2012-08-07 14:35:05 UTC
Permalink
Post by Jan Danielsson
[---]
Post by Stephan Beal
Another consideration here is that the wiki has kind of fallen out of use,
[---]
I don't know that that is true. The only proof of this I have seen
prior to this thread is that at times it's mentioned that the fossil
repository uses embedded wiki rather than the "built in" wiki.
Hear hear. All that means is that wikis aren't the best way of handling
documentation for an open source project; it is indeed better to version
documents as part of the source code tree.

However, wikis are ideal for user-contributed material that's attached
to an open-source project, and documents relating to that project with a
scope beyond a particular revision of the project itself.

Also, wikis are editable in the browser, making them far more accessible
for contribution than embedded documentation.

I have a fossil repo for my house. The wiki is served up from the home
fileserver and contains recipies, useful information for visitors, and
stuff like that. I have tickets for DIY projects and things we need to
buy. And the filesystem repo contains important documents pertaining to
the house. I've set up web permissions so that only logged-in users can
get beyond the wiki.

On the other hand, my open source projects at
http://www.kitten-technologies.co.uk/ are all cgi-hosted Fossil repos
(the front site itself is static HTML, but generated from stuff in a
fossil repo - see
http://www.kitten-technologies.co.uk/project/kitten-technologies and a
typical project such as
http://www.kitten-technologies.co.uk/project/ugarit), all heavily based
around embedded documentation; I'll do things with the inbuilt wiki if a
user community develops around any of them and non-contributors seem to
want to contribute stuff!

ABS

- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
Stephan Beal
2012-08-07 17:29:50 UTC
Permalink
I have a fossil repo for my house. The wiki is served up from the home...
i'm willing to bet that that's a use case none of us foresaw.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Stephan Beal
2012-08-03 12:57:36 UTC
Permalink
On Fri, Aug 3, 2012 at 12:19 PM, Michal Suchanek
...not to decide that but I have to agree. Once you let in markdown
people used to some other wiki syntax would argue they have needlessly
hard time and there would be no end to the stream of requests to
include yet another.
Hi Michal,

For what it's worth (i'm summarizing here because i suspect that you missed
the past 37302 threads on this topic ;)... Yes, you are absolutely correct
(IMO) on each of your points. The fact is, however, that MD support has
probably been the single most-requested feature (possibly as a side-effect
of github?) in terms of fossil's wiki support. That gives it a bit more
weight, in my opinion (even though i don't personally like MD).

That said: in several of my fossil wikis i store Google Code format in the
wiki and render it client-side. My only point there is that it _is_
currently possible to integrate any wiki format(s) you want to as long as
you can render them client-side, and if you are using multiple formats you
need a way of differentiating them (so you know which rendered to use),
e.g. via a naming convention or a special markup tag in the first line, or
similar.

Here's an example which uses GoCo format exclusively:

http://fossil.wanderinghorse.net/wikis/cson/

(That doesn't look much like Fossil as you know it, but it is a custom UI
implemented on top of the JSON API.)
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Remigiusz Modrzejewski
2012-08-03 13:14:48 UTC
Permalink
Post by Stephan Beal
That said: in several of my fossil wikis i store Google Code format in the
wiki and render it client-side. My only point there is that it _is_
currently possible to integrate any wiki format(s) you want to as long as
you can render them client-side, and if you are using multiple formats you
need a way of differentiating them (so you know which rendered to use),
e.g. via a naming convention or a special markup tag in the first line, or
similar.
Is it possible to bundle this solution into a single binary like the original Fossil?


Kind regards,
Remigiusz Modrzejewski
Stephan Beal
2012-08-03 13:22:08 UTC
Permalink
On Fri, Aug 3, 2012 at 3:14 PM, Remigiusz Modrzejewski
Post by Remigiusz Modrzejewski
Is it possible to bundle this solution into a single binary like the original Fossil?
http://fossil.wanderinghorse.net/repos/fwiki/

and 3 demos of it are here:

http://fossil.wanderinghorse.net/repos/fwiki/editor/

There isn't a binary, per se, just a collection of html/js/css.

Consider all of that experimental, though - it's where i do most of the
dev/testing of the JSON API nowadays. The "fwiki" code is where i am trying
to evolve a set of widgets for the JSON API, such that users could combine
that with the up-coming custom pages support to literally replace the HTML
interface with something more to their liking. e.g. i want various timeline
widgets, user list/editor, a ticket overview widget (tickets are more
difficult for the JSON API than they might sound because they can be
customized considerably), etc. But there are only so many hours in a day,
and i'm already way over my limit, so progress is slow... :/ (Collaborators
are ALWAYS welcomed, hint, hint! ;)
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Michal Suchanek
2012-08-03 13:22:18 UTC
Permalink
Post by Remigiusz Modrzejewski
Post by Stephan Beal
That said: in several of my fossil wikis i store Google Code format in the
wiki and render it client-side. My only point there is that it _is_
currently possible to integrate any wiki format(s) you want to as long as
you can render them client-side, and if you are using multiple formats you
need a way of differentiating them (so you know which rendered to use),
e.g. via a naming convention or a special markup tag in the first line, or
similar.
Is it possible to bundle this solution into a single binary like the original Fossil?
In current fossil you would have to patch the JavaScript code into the
HTML template that is in the fossil code and rebuild fossil. This is
obviously problematic because you will have to provide binaries for
all platforms you want to support.

When user HTML templates are implemented it will be possible to store
in the HTML template, presumably as part of configuration that can be
replicated along with the repository content.

Thanks

Michal
Richie Adler
2012-08-03 16:59:42 UTC
Permalink
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
Note there are JavaScript hacks for interpreting random wiki syntax so
you can have markdown interpreted without any direct support in
fossil.
Note there are good wiki engines out there, so no need for one in Fossil
too. But once we set the scope to include something, please don't keep it
half-hearted...
And it has been said that markdown is out of the scope of Fossil. I am not
to decide that but I have to agree. Once you let in markdown people used to
some other wiki syntax would argue they have needlessly hard time and there
would be no end to the stream of requests to include yet another.
Wholeheartedly agreed. Let's stop with the wiki markup discussions and keep
the list DSCM related... PLEASE.
--
o-=< Marcelo >=-o
Michal Suchanek
2012-08-03 10:19:01 UTC
Permalink
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
+1
Why markdown and not one of the dozens of other wiki syntaxes?
Because markdown is a very popular one, used by github, and we have on board the creator of a major implementation (the one used by github, iirc).
The others are also very popular.

Github has a cute logo but I would not turn to it when looking for
sound technical solutions.
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
I don't find wiki syntaxes really easy. Maybe a bit easier to type
than HTML but definitely not easy to read or remember, especially
since there are dozens of slightly (and not so slightly) different
variants.
That's why half of the web seems to standarize on markdown. The same web that was mostly writing HTML a few years ago.
Does not seem that way to me.

I deal with sites using various wiki format variations.

If you want to make your point on that then supply more data, please.
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
Note there are JavaScript hacks for interpreting random wiki syntax so
you can have markdown interpreted without any direct support in
fossil.
Note there are good wiki engines out there, so no need for one in Fossil too. But once we set the scope to include something, please don't keep it half-hearted...
And it has been said that markdown is out of the scope of Fossil. I am
not to decide that but I have to agree. Once you let in markdown
people used to some other wiki syntax would argue they have needlessly
hard time and there would be no end to the stream of requests to
include yet another.

Thanks

Michal
Michal Suchanek
2012-08-03 10:19:01 UTC
Permalink
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
+1
Why markdown and not one of the dozens of other wiki syntaxes?
Because markdown is a very popular one, used by github, and we have on board the creator of a major implementation (the one used by github, iirc).
The others are also very popular.

Github has a cute logo but I would not turn to it when looking for
sound technical solutions.
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
I don't find wiki syntaxes really easy. Maybe a bit easier to type
than HTML but definitely not easy to read or remember, especially
since there are dozens of slightly (and not so slightly) different
variants.
That's why half of the web seems to standarize on markdown. The same web that was mostly writing HTML a few years ago.
Does not seem that way to me.

I deal with sites using various wiki format variations.

If you want to make your point on that then supply more data, please.
Post by Remigiusz Modrzejewski
Post by Michal Suchanek
Note there are JavaScript hacks for interpreting random wiki syntax so
you can have markdown interpreted without any direct support in
fossil.
Note there are good wiki engines out there, so no need for one in Fossil too. But once we set the scope to include something, please don't keep it half-hearted...
And it has been said that markdown is out of the scope of Fossil. I am
not to decide that but I have to agree. Once you let in markdown
people used to some other wiki syntax would argue they have needlessly
hard time and there would be no end to the stream of requests to
include yet another.

Thanks

Michal
Rene
2012-08-03 13:41:07 UTC
Permalink
Post by Michal Suchanek
Post by Gautier DI FOLCO
Post by Bill Burdick
I'd like to see it included, as well!
I'd like it too, it will be easier for beginnes (like me!).
+1
Why markdown and not one of the dozens of other wiki syntaxes?
I don't find wiki syntaxes really easy. Maybe a bit easier to type
than HTML but definitely not easy to read or remember, especially
since there are dozens of slightly (and not so slightly) different
variants.
Note there are JavaScript hacks for interpreting random wiki syntax so
you can have markdown interpreted without any direct support in
fossil.
Thanks
Michal
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Nice things are starting to heat up :-) let me throw some oil on the
fire.



I don't find any wiki syntaxes to be what you need. At one point they
all fall short.
However writing html isn't my favourite therapy and there a wiki syntax
can be handy.

I'm quite pleased as a wiki "language" takes 80% of my hands.

The advantage of this particular implementation is that it is C coded
and that the license is compatible with fossil.
And with Nataschsa's extension it becomes workable.

I rather write
------------------------------------------------
![class:centered_image](branch05.gif =485x177)\
figure 5
------------------------------------------------
{on a side note I would prefer this
![class:centered_image,=485x177](branch05.gif)\
because a pure markdown implementation would still get the
link right only the description
is strange. and in The above example a pure markdown will
not get the link right}
then

<center><table border=1 cellpadding=10 hspace=10 vspace=10>
<tr><td align="center">
<img src="branch05.gif" width=485 height=177><br>
Figure 5
</td></tr></table></center>

But this could have been written like

<table class="table_centered_image"><tr><td><img src="branch05.gif"
width=485 eight=177><br> Figure
5</td></tr></table>

or maybe like
<div class="centered_image"> <img src="branch05.gif" width=485
eight=177><br>Figure 5</div>

in general tag languages can get rather verbose!
But still the Markdown version ( and most wiki's), IMHO, is, slightly,
better readable.

Your suggestion to use javascript to display wiki markup is possible.
and interesting

what do we do with the javascript library?
it is not part of your project which will deliver fantastic software
without markdown.


So is it part of fossil?
If you clone the repo than you want the same kind of services as the
original.
How can that be done in a consistent manor?
It gives me a headache to think that out.
Of course you don't want MarkDown but you want MarkUp. Stephen will say
that you have to resort to JSON.
maybe that is the right answer.

On his site http://daringfireball.net/projects/markdown/ the markdown
inventor says
"The idea is that a Markdown-formatted document should be
publishable as-is, as plain text,
without looking like it’s been marked up with tags or formatting
instructions."
I think it looks awkward any way.
--
Rene
Natacha Porté
2012-08-03 08:39:49 UTC
Permalink
Hello,
Post by Stephan Beal
Post by Natacha Porté
+ review my code to ensure it meets fossil level of quality,
+ format it using fossil code style if needed,
+ any other code change that comes up during the review.
i will be happy to offer my 0.0163 Euros, but i won't be able to do so
until later in the week. Richard is, from what i understand, swamped for
the foreseeable future.
No problem at all, I'm genuinely that patient. You could tell me nobody
would have time to look at it in 2012, and that would be fine with me
and I wouldn't send any other reminder before end of Januray 2013.
Post by Stephan Beal
Of course, anyone else is encouraged to help :).
Indeed, all constructive criticism about my code is always welcome, even
if the code turns out to be eventually rejected. That's how I have
always been able to make any progress in my programming skills.
Post by Stephan Beal
While i don't personally use MD i'd like to see it added if only because
people keep asking about it ;). Maybe then some of the religious wars can
end ;).
And some other can start, for example which superset of Markdown to
settle for :-)

And this is only half a joke, since raw Markdown is quite limited, and
its inventor refuses any further evolution. So most software actually
supports a kind of extended Markdown, but there is little consistency in
the exact set of extensions. It's Babel all over again.

I didn't mention that as an open question, because that will be moot if
the library is rejected, but before having a real markdowned-fossil
release the question will have to be answered.
Post by Stephan Beal
i will post back once i have looked over it. Would you prefer that i send
comments regarding it to the list or to you directly?
I don't have any preference in that regard, either way suits me as
well. So I guess it boils down to whether the rest of the list is
interested in such comments or whether they would rather avoid the extra
spam.
Post by Stephan Beal
And thank you for your contribution and persistence.
Sure :-) And thank you for the heartwarming answer ^^

Still, I'm never sure where is the line between persistence as a good
trait and persistence as a bad one. I hope I haven't crossed it yet.
Post by Stephan Beal
To be clear: the final decision about what goes in to the trunk belongs to
Richard and Richard alone. The other contributors, such as a myself, are
here to assist, but the final decision rests with him. For what i'd worth,
i'd like to see it included (but would like to look at the code first ;).
Of course, that's as much as I expected. I consider any comment on my
code I get from here as a privilege.


Thanks for your interest,
Natacha Porté
Stephan Beal
2012-08-03 12:51:37 UTC
Permalink
Post by Natacha Porté
No problem at all, I'm genuinely that patient. You could tell me nobody
would have time to look at it in 2012, and that would be fine with me
and I wouldn't send any other reminder before end of Januray 2013.
No, no, you've been exceedingly patient and politely persistent, and a
review is on my list for tonight/tomorrow :).
Post by Natacha Porté
if the code turns out to be eventually rejected. That's how I have
always been able to make any progress in my programming skills.
That's a health world-view in my experience :).
Post by Natacha Porté
And some other can start, for example which superset of Markdown to settle
for :-)
LOL - yes, i saw a bit of that starting in one of the responses.
Post by Natacha Porté
And this is only half a joke, since raw Markdown is quite limited, and
its inventor refuses any further evolution. So most software actually
supports a kind of extended Markdown, but there is little consistency in
the exact set of extensions. It's Babel all over again.
Another argument for just sticking with plain HTML ;).
Post by Natacha Porté
i will post back once i have looked over it. Would you prefer that i send
Post by Stephan Beal
comments regarding it to the list or to you directly?
I don't have any preference in that regard, either way suits me as
well. So I guess it boils down to whether the rest of the list is
interested in such comments or whether they would rather avoid the
extra spam.
If you are on the fossil-dev list i can send them there (most people on
this list aren't interested in geeky details, i think).
Post by Natacha Porté
Still, I'm never sure where is the line between persistence as a good
trait and persistence as a bad one. I hope I haven't crossed it yet.
Not at all (at least not in my opinion).

i'll start feeding back code comments in the next 24 hours or so.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Natacha Porté
2012-09-03 10:40:27 UTC
Permalink
Hello,
Post by Stephan Beal
Post by Natacha Porté
+ review my code to ensure it meets fossil level of quality,
+ format it using fossil code style if needed,
+ any other code change that comes up during the review.
i will be happy to offer my 0.0163 Euros, but i won't be able to do so
until later in the week. Richard is, from what i understand, swamped for
the foreseeable future. Of course, anyone else is encouraged to help :).
While i don't personally use MD i'd like to see it added if only because
people keep asking about it ;). Maybe then some of the religious wars can
end ;).
[...]
To be clear: the final decision about what goes in to the trunk belongs to
Richard and Richard alone. The other contributors, such as a myself, are
here to assist, but the final decision rests with him. For what i'd worth,
i'd like to see it included (but would like to look at the code first ;).
I was just wondering whether I have been missing something.

Would you or anyone from the list confirm whether at this point I only
have to wait for Richard's review and approval, or is there something I
forgot to perform before that can happen?


Thanks for your help,
Natacha Porté

Rene
2012-07-30 19:29:15 UTC
Permalink
Post by Natacha Porté
Hello,
I don't want to look impatient, and I personally hate to be
constantly
reminded about something that hasn't actually left my mind, so I'm a bit
reluctant to send e-mails like this one. All my apologies if I'm doing
it wrong.
So my point is only to remind you all that I'm still committed to make
the fossil-in-markdown thing going forward, and I'm eagerly waiting any
instructions on what to do about it next.
Currently the code is in a new branch off a clone of the official fossil
repository, available at
http://fossil.instinctive.eu/fossil-scm/timeline?r=markdown
There is also a live demo (dedicated repository served using a fossil
compiled off this branch) at
http://fossil.instinctive.eu/markdown-examples/doc/tip/README.mkd
+ complete and seamless integration of the markdown engine into fossil
(e.g. using fossil blobs as dynamic buffers),
+ support of markdown embedded documentation (.markdown and .mkd
extensions), using current fossil style,
+ regular merge of latest changes from trunk.
+ review my code to ensure it meets fossil level of quality,
+ format it using fossil code style if needed,
+ any other code change that comes up during the review.
I'm still willing to perform any maintenance needed on the markdown
library code and/or the glue between it and fossil, for as long as I
can. I would also gladly handle any knowledge-transfer needed to prevent
myself from being a single point of failure in the maintenance of that
code.
Thanks for your interest,
Natacha Porté
Are we going to move all the wikipages to markdown? I converted the
attached file to markdown it wasn't to difficult with
bit of sed, awk and pandoc.
What do you see as an advantage of markdown compared to the current
wiki syntax?
--
Rene
Stephan Beal
2012-07-30 22:52:14 UTC
Permalink
Post by Rene
Are we going to move all the wikipages to markdown?
The main repo doesn't use wiki pages any more - the embedded docs feature
is preferred because it's versioned along with the rest of the site. Wikis
_are_ versioned but there is no UI for traversing specific versions or
referencing them from [wikiLinks], etc., so they don't tend to get used
much. i use them a bit in my own sites, but half of those are running a
custom Google Code syntax renderer on top of a fossil back-end, using the
JSON API to transport it, e.g.:

http://fossil.wanderinghorse.net/wikis/cson/

that's a fossil back-end with a completely custom front-end which reveals
only the wiki to the user.
Post by Rene
I converted the attached file to markdown it wasn't to difficult with
bit of sed, awk and pandoc.
What do you see as an advantage of markdown compared to the current wiki
syntax?
Here's a similar script for fossil-to-GoogleCode format can probably be
re-used a bit for markdown:

http://whiki.wanderinghorse.net/?page=fossil2whiki.sh

Happy Hacking!
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Bill Burdick
2012-07-30 22:58:53 UTC
Permalink
Looks like it's using wiki pages, to me, just not stored in the Fossil wiki
-- at least, that what the "Editor" button tells me... :)
Post by Stephan Beal
Post by Rene
Are we going to move all the wikipages to markdown?
The main repo doesn't use wiki pages any more - the embedded docs feature
is preferred because it's versioned along with the rest of the site. Wikis
_are_ versioned but there is no UI for traversing specific versions or
referencing them from [wikiLinks], etc., so they don't tend to get used
much. i use them a bit in my own sites, but half of those are running a
custom Google Code syntax renderer on top of a fossil back-end, using the
http://fossil.wanderinghorse.net/wikis/cson/
that's a fossil back-end with a completely custom front-end which reveals
only the wiki to the user.
Post by Rene
I converted the attached file to markdown it wasn't to difficult with
bit of sed, awk and pandoc.
What do you see as an advantage of markdown compared to the current wiki
syntax?
Here's a similar script for fossil-to-GoogleCode format can probably be
http://whiki.wanderinghorse.net/?page=fossil2whiki.sh
Happy Hacking!
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Bill Burdick
2012-07-30 23:00:06 UTC
Permalink
Very slick front-end, BTW!
Post by Bill Burdick
Looks like it's using wiki pages, to me, just not stored in the Fossil
wiki -- at least, that what the "Editor" button tells me... :)
Post by Stephan Beal
Post by Rene
Are we going to move all the wikipages to markdown?
The main repo doesn't use wiki pages any more - the embedded docs feature
is preferred because it's versioned along with the rest of the site. Wikis
_are_ versioned but there is no UI for traversing specific versions or
referencing them from [wikiLinks], etc., so they don't tend to get used
much. i use them a bit in my own sites, but half of those are running a
custom Google Code syntax renderer on top of a fossil back-end, using the
http://fossil.wanderinghorse.net/wikis/cson/
that's a fossil back-end with a completely custom front-end which reveals
only the wiki to the user.
Post by Rene
I converted the attached file to markdown it wasn't to difficult with
bit of sed, awk and pandoc.
What do you see as an advantage of markdown compared to the current wiki
syntax?
Here's a similar script for fossil-to-GoogleCode format can probably be
http://whiki.wanderinghorse.net/?page=fossil2whiki.sh
Happy Hacking!
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Stephan Beal
2012-07-31 16:58:04 UTC
Permalink
Post by Bill Burdick
Very slick front-end, BTW!
i appreciate the compliment, but we all know i have no gift for visual
design ;). i had a designer at work help me out with the css, so it doesn't
look half as bad as it originally did, but it could certainly be made
prettier by someone who has a knack for that sort of thing.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Stephan Beal
2012-07-31 16:57:00 UTC
Permalink
Post by Bill Burdick
Looks like it's using wiki pages, to me, just not stored in the Fossil
wiki -- at least, that what the "Editor" button tells me... :)
They are actually stored in fossil, but not in the same repo as the
sources. i don't want fossil mis-rendering the Google Code pages, so i hide
those in their own repo and only expose them via my ui.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Stephan Beal
2012-08-03 17:11:24 UTC
Permalink
Post by Natacha Porté
Currently the code is in a new branch off a clone of the official fossil
repository, available at
http://fossil.instinctive.eu/fossil-scm/timeline?r=markdown
Can you please update your fossil binary so that:

/vdiff?branch=markdown

will work?

That makes looking at branch-wide diffs MUCH simpler :).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Natacha Porté
2012-08-03 17:30:42 UTC
Permalink
Hello,
Post by Stephan Beal
Post by Natacha Porté
Currently the code is in a new branch off a clone of the official fossil
repository, available at
http://fossil.instinctive.eu/fossil-scm/timeline?r=markdown
/vdiff?branch=markdown
will work?
That makes looking at branch-wide diffs MUCH simpler :).
Done (actually since there is no new packaged version, I justed
configured it to use trunk+markdown binary instead of the "stable"
system binary).

Moreover, I have just subscribed to fossil-dev, in case you wish to move
part of the discussion there.


Natacha Porté
Continue reading on narkive:
Loading...