Hello, on Friday 03 August 2012 at 13:41, Michal Suchanek wrote: > On 3 August 2012 13:04, Natacha Porté <nata...@instinctive.eu> wrote: > > As a user, the killer feature I see for markdown is that the > > implementation exists (assuming my code is considered worthy, which is > > quite a strong assumption, but without it everything else is moot > > anyway, so I'll keep the assumption in this e-mail). Code that exists > > wins over code that does not. We can discuss for days about the best > > markup syntax, it's completely useless when there is nobody to actually > > implement it. > > By the extension of this very argument, code that exists in-tree beats > code that exists out of tree. So the current syntax wins.
Indeed. And that's the only reason I've ever used it.
But now, on the binaries I use, both exist. So as far as I'm concerned,
they are both as accessible, and the tie is broken by my preference on
Markdown. And the only reason I'm posting to this list is to propose
such a situation to anyone interested.
> I have strong objections about all such makups, none is perfect, all
> have some annoyances, and they are all mutually incompatible.
>
> Changing from one to another does not improve things, however. It only
> brings incompatible repositories into existence.
You're going much further than I am here. What I have proposed does not
introduce any incompatibility at all. I have only included the markdown
engine and used it for inline ("embedded doc") rendering of .mkd and
.markdown files in the repository.
As I have said elsewhere, I'm not clever enough to imagine a solution to
introduce markdown into fossil's internal wiki. So I don't propose it. I
propose the extra embedded doc rendering, and the tools to perform any
markdown-to-html conversion. When someone comes up with a way to deal
with the internal wiki, they will have such tools.
> >> I am
> >> not to decide that but I have to agree. Once you let in markdown
> >> people used to some other wiki syntax would argue they have needlessly
> >> hard time and there would be no end to the stream of requests to
> >> include yet another.
> >
> > I think it's very useful to distinguish between requests to write code in
> > order to include yet another, and requests to officially mirror a branch
> > containing ready-to-use code that includes yet another.
> >
> > Surely the stream of the second kind of requests would be much lighter
> > than the stream of the first kind, wouldn't it?
> >
> > And as far as requests of the second kind goes, if the code is good
> > enough and does not bloat the project, why not accept them? (in the
> > context that assumes markdown has already been let in)
>
> Because of compatibility with existing repositories that use the
> current syntax which is not compatible with markdown.
Well remember that I assumed markdown already in, and therefore this
objection already correctly addressed. So that does not qualifies as a
reason to not accept further code.
> As you did not include a link to your repository of markdown enabled
> fossil I cannot tell how it addresses compatibility.
I did. In the very first post of this thread.
Natacha Porté
pgptKo5tlfz7o.pgp
Description: PGP signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
