Now to refute this. Keep in mind that if I had my 'druthers I'd have
Markdown as well while you read this.
Markdown is a non-trivial format to parse and implement. The resulting code
is non-trivial in size as well. Not everybody universally accepts Markdown
as the format they want. Others want, say, Textile. Or Creole. Or
Wikimedia. Or Wikidot. Or ...
That is the problem. There's too many choices out there and the choices are
not even vaguely compatible with each other. Is Fossil's wiki syntax weak?
Yes. Does this mean we should replace it with some other format? Quite
possibly. But until there is a clear winner in the format wars with
libraries that can be easily integrated (both technically and legally) it
probably isn't going to happen, and as much as it pains me--as a Markdown
fan--to say this, I agree with Richard's decision reasoning.
The alternatives are:
- Go through all this whining all over again whenever a new format is
selected. ("But why did you pick MAAAAAAAAAAAARKdoooooooown?! Creole is
SOOOOOOOOOOO much better because....")
- Go through some incredible code bloat as every format under the sun is
hacked in.
- Lose one of the key attractions to Fossil as repositories get subtly
incompatible with each other as this one over here has this obscure markup
language hacked in for markup on MacOS that doesn't work on Linux or Windows
or ...
Personally I don't view the Wiki part of Fossil so important as to put up
with all of that constantly. I far prefer the rock-solid database core, the
single-executable/single-file-repositories nature, the integrated web
services, the built-in ticket management, etc. When I want to do detailed
docs with fancy formatting I put it in the documentation tree of the actual
source code, not the Wiki. The Wiki seems more suited to quick notes and
the like anyway. Could the wiki be more by switching formats? Almost
certainly. But the costs are likely too high.
2009/11/29 Joshua Paine <jos...@letterblock.com>
> On Sat, 2009-11-28 at 09:10 -0500, D. Richard Hipp wrote:
> > http://www.fossil-scm.org/fossil/wiki_rules
>
> I re-read this and noticed again the rationale for using the simple wiki
> rules included instead of an existing wiki language. Given the
> rationale, I think Markdown would be a better choice.
>
> > 1. There is no standard wiki markup language. Every wiki engine does
> > it a little differently.
>
> There are only a small handful of popular wiki languages. Some
> implementations may have more or less features (e.g., Markdown
> implementations in various languages), but in the case of Markdown at
> least there is a common core with a test suite which nearly all
> implementations pass.
>
> Fossil itself is an example of looking at an already-crowded field and
> deciding to start over a bit differently anyway, and I'm glad of it: I
> find fossil easy to understand, and publishing repositories together
> with documentation and issue tracking is shockingly easy. But surely
> having many existing options is not in itself a reason to start over?
> Unlike fossil as a whole vs other SCMs, the wiki formatting provides no
> advantages at all vs markdown, at least from a user perspective.
>
> > 2. The wiki markup used by fossil, though limited, is common to most
> > other wiki engines, is intuitive, and is sufficient for 90% of all
> > formatting tasks.
>
> SVN was sufficient for 90%+ of my SCM tasks until I learned about the
> power of easy branching and merging and distributed development from git
> and the power of built-in collaboration tools and trivial publishing
> from fossil. For composing text, though, I'm already used to the power
> and flexibility of markdown, and fossil wiki doesn't meet 90% of my
> needs--anymore than I'd still be content with SVN.
>
> > 3. Where the fossil wiki markup language is insufficient, HTML is
> > used. ... HTML does not need to be used very often so is not a burden.
>
> > The formatting rules for fossil wiki are designed to be simple and
> > intuitive. ... with a safe subset of HTML for more complex formatting
> > tasks.
>
> This is what it really comes down to, isn't it? The formatting should be
> simple and familiar, and it should be easy easy easy to fall back to
> HTML for whatever you need.
>
> Until this evening I hadn't deeply investigated the other wiki formats.
> I was surprised to discover that it's not trivial to just use HTML in
> any of them! That being the case, perhaps you weren't aware that using
> HTML *is* trivial with markdown? You can freely mix plain HTML in with
> the markdown formatting without any special escaping.
>
> So for the same feature set, markdown is at least as intuitive as fossil
> wiki, it provides convenient and intuitive formatting for a larger set
> of text composition needs, and using HTML is just as easy in markdown as
> in fossil wiki.
>
> I see two ties and one win for markdown. Consider also that with
> markdown the wiki formatting would not be *similar* to most other wiki
> engines, it would *be* one of the two most popular text formatting
> engines. Markdown is a very well thought-out format by a guy who spends
> a lot of time focused on writing, HTML, and writing-with-and-about-HTML.
> I'm pretty sure if John Gruber (creator of markdown) needed an embedded
> database, he'd just use SQLite and never even consider writing his own.
> With all respect to one of my programming role models, I think
> DRH--needing a convenient, HTML-compatible wiki format--should just use
> Markdown: the one very popular already-existing format that supports
> painless inline HTML.
>
> ---------------------------------
>
> >From a user perspective, I think markdown is a clear win. But I don't
> know much about the implementation. The 'discount' library Michael
> Richter linked earlier is released under a permissive license, but it's
> one that may not be compatible with GPL 2. I've written the author to
> see if he would consider one of the definitely-GPL-compatible permissive
> licenses, but I don't know him at all and have no idea if I'll even hear
> anything back. If markdown integration or implementation (as necessary)
> isn't worth the trouble right now, I hope you'll at least move it from a
> "wontfix" to "patches accepted".
>
> --
> Joshua Paine
> LetterBlock: Web applications built with joy
> http://letterblock.com/
> 301-576-1920
>
> _______________________________________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
