On Thursday, 14 December 2017 at 10:39:02 UTC, Chris wrote:
On Tuesday, 12 December 2017 at 18:14:18 UTC, Jakob Bornecrantz
wrote:
It's a language a small group of people (me included) have
been working on for a while, I avoid naming it here because
it's a system level language like D. I do
On Wednesday, 6 December 2017 at 09:33:47 UTC, Sönke Ludwig wrote:
Am 06.12.2017 um 05:11 schrieb Walter Bright:
https://help.github.com/articles/basic-writing-and-formatting-syntax/
Anyone interested in picking up the flag?
(I know this has come up before, and I've been opposed to it,
but I'
On Tuesday, 12 December 2017 at 18:14:18 UTC, Jakob Bornecrantz
wrote:
It's a language a small group of people (me included) have been
working on for a while, I avoid naming it here because it's a
system level language like D. I don't want to advertise it in
any form here to keep the discus
On Tuesday, December 12, 2017 16:12:50 Adam D. Ruppe via Digitalmars-d
wrote:
> On Tuesday, 12 December 2017 at 11:33:45 UTC, Jonathan M Davis
>
> wrote:
> > Personally, I would _very_ much like to see the magic
> > formatting in ddoc kept to a minimum.
>
> You know what drives me nuts? This* is w
On Tuesday, 12 December 2017 at 02:30:39 UTC, Walter Bright wrote:
On 12/11/2017 2:30 PM, Jakob Bornecrantz wrote:
It is not written in D, but the language is close enough in
concepts that it can be mechanically ported into D, and is
licensed under BOOST. Feel free to do what ever to it[1].
T
On Tuesday, 12 December 2017 at 16:12:50 UTC, Adam D. Ruppe wrote:
Ugh. Or why is _this_ italic?
I know! /This should be italic./ _This should be underlined._ How
anyone could manage to mess those up is way beyond me. Some
digging indicates it's a decision based on the fact that both are
use
On Tuesday, 12 December 2017 at 11:33:45 UTC, Jonathan M Davis
wrote:
Personally, I would _very_ much like to see the magic
formatting in ddoc kept to a minimum.
You know what drives me nuts? This* is weird.
* it is rendered as a list item! And I know, you can do \*. But
ugh.
Ugh. Or why is
On Tuesday, 12 December 2017 at 15:59:42 UTC, John Gabriele wrote:
On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright
wrote:
I have a more pragmatic definition of a standard:
1. Products that implement it say they adhere to it and defer
to it as the authority on correct behavior.
2.
On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright wrote:
I have a more pragmatic definition of a standard:
1. Products that implement it say they adhere to it and defer
to it as the authority on correct behavior.
2. There's more than one such product.
3. There's more products adher
On Sunday, 10 December 2017 at 06:20:43 UTC, Walter Bright wrote:
Besides, commonmark has a lot of stuff we don't need, like
multiple ways of doing the same thing.
We would have to come with style guidelines to avoid a mix of say:
*italic* and _italic_
# Heading 1 and
Heading 1
==
B
On Tuesday, 12 December 2017 at 13:50:42 UTC, Bastiaan Veelo
wrote:
On Tuesday, 12 December 2017 at 11:48:24 UTC, Chris wrote:
On Tuesday, 12 December 2017 at 11:33:45 UTC, Jonathan M Davis
wrote:
And then you have to worry about something like int* screwing
with things, because the compiler
On Tuesday, 12 December 2017 at 13:50:42 UTC, Bastiaan Veelo
wrote:
On Tuesday, 12 December 2017 at 11:48:24 UTC, Chris wrote:
On Tuesday, 12 December 2017 at 11:33:45 UTC, Jonathan M Davis
wrote:
And then you have to worry about something like int* screwing
with things, because the compiler
On Tuesday, 12 December 2017 at 11:48:24 UTC, Chris wrote:
On Tuesday, 12 December 2017 at 11:33:45 UTC, Jonathan M Davis
wrote:
And then you have to worry about something like int* screwing
with things, because the compiler decides that you wanted
italics. Honestly, I don't think that someth
On Tuesday, 12 December 2017 at 11:48:24 UTC, Chris wrote:
Try this one (paste it into http://spec.commonmark.org/dingus/):
# CommonMark
```
int* ptr;
```
`int*` is a pointer to an integer.
int* is a pointer to an integer.
The output is
CommonMark
int* ptr;
int* is a pointer to a
On Tuesday, 12 December 2017 at 11:33:45 UTC, Jonathan M Davis
wrote:
And then you have to worry about something like int* screwing
with things, because the compiler decides that you wanted
italics. Honestly, I don't think that something like $(I foo)
is very onerous - it's not all that diffe
On Tuesday, December 12, 2017 10:22:24 meppl via Digitalmars-d wrote:
> On Tuesday, 12 December 2017 at 06:55:45 UTC, Jonathan M Davis
>
> wrote:
> > On Tuesday, December 05, 2017 20:11:33 Walter Bright via
> >
> > Digitalmars-d wrote:
> >> https://help.github.com/articles/basic-writing-and-formatt
Compare:
Output:
https://github.com/vibe-d/vibe.d/blob/master/README.md
Input:
https://raw.githubusercontent.com/vibe-d/vibe.d/master/README.md
Most programmers who use GitHub will be familiar with this and
can write docs, tutorials etc. with very little effort. The set
of Markdown used for t
On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright wrote:
I have a more pragmatic definition of a standard:
1. Products that implement it say they adhere to it and defer
to it as the authority on correct behavior.
2. There's more than one such product.
You have to start somewhere.
On Tuesday, 12 December 2017 at 06:55:45 UTC, Jonathan M Davis
wrote:
On Tuesday, December 05, 2017 20:11:33 Walter Bright via
Digitalmars-d wrote:
https://help.github.com/articles/basic-writing-and-formatting-syntax/
Anyone interested in picking up the flag?
(I know this has come up before, a
On Tuesday, December 05, 2017 20:11:33 Walter Bright via Digitalmars-d
wrote:
> https://help.github.com/articles/basic-writing-and-formatting-syntax/
>
> Anyone interested in picking up the flag?
>
> (I know this has come up before, and I've been opposed to it, but I've
> changed my mind.)
I conf
On Monday, 11 December 2017 at 15:45:07 UTC, Guillaume Piolat
wrote:
On Monday, 11 December 2017 at 14:22:37 UTC, Jakob Bornecrantz
wrote:
And to add more, CommonMark on the other hand has a full spec
written and several test that covers the difficult to get
right parts of Markdown/CommonMark
On Tuesday, 12 December 2017 at 02:30:39 UTC, Walter Bright wrote:
It's apparently written in Volt:
https://github.com/VoltLang/Watt
But the two links there to Volt are dead:
https://github.com/VoltLang/Watt/blob/master/volt-lang.org
Ah, the joys of forgetting too ensure URLs in Markdown REA
On 12/11/2017 2:30 PM, Jakob Bornecrantz wrote:
It is not written in D, but the language is close enough in concepts that it can
be mechanically ported into D, and is licensed under BOOST. Feel free to do what
ever to it[1].
Thank you for Boost licensing it!
We first used the markdown parser
On 12/11/2017 2:30 PM, Jakob Bornecrantz wrote:
What I'm trying to get at is, use the testsuit and spec, it will save you lot of
other problems down the road. And you will be making the world of Markdown a
better place because there will be one less implementation that does things
slightly diff
On Monday, 11 December 2017 at 20:45:38 UTC, Walter Bright wrote:
On 12/11/2017 6:22 AM, Jakob Bornecrantz wrote:
There are loads of implementations of CommonMark
https://github.com/commonmark/CommonMark/wiki/List-of-CommonMark-Implementations
They appear to be libraries that offer an implemen
On 12/11/17 1:45 PM, Walter Bright wrote:
On 12/11/2017 6:22 AM, Jakob Bornecrantz wrote:
There are loads of implementations of CommonMark
https://github.com/commonmark/CommonMark/wiki/List-of-CommonMark-Implementations
They appear to be libraries that offer an implementation. Does the
Mark
On 12/11/2017 6:22 AM, Jakob Bornecrantz wrote:
There are loads of implementations of CommonMark
https://github.com/commonmark/CommonMark/wiki/List-of-CommonMark-Implementations
They appear to be libraries that offer an implementation. Does the Markdown used
in github, reddit, wikipedia, doxy
On 12/11/2017 11:29 AM, John Gabriele wrote:
Right. That said, if you want to add a handful of markdown-ish features, I think
it would be most useful to draw your very limited markdown subset from the
CommonMark markdown spec. The other option takes you down the road of
unintentionally creating
On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright wrote:
Don't get me wrong, I think commonmarkdown is a worthy effort,
and is definitely in the running to be a standard. Certainly a
lot more effort seems to have been put into it vs other
markdowns.
Note that CommonMark isn't simply
On Monday, 11 December 2017 at 15:45:07 UTC, Guillaume Piolat
wrote:
The CommonMark approach is to just take the union of all
possible features and call it a day.
Standards without opinions don't deserve to be implemented by
anyone.
I disagree. If anything, it's more of a subset of features
On Monday, 11 December 2017 at 15:45:07 UTC, Guillaume Piolat
wrote:
On Monday, 11 December 2017 at 14:22:37 UTC, Jakob Bornecrantz
wrote:
And to add more, CommonMark on the other hand has a full spec
written and several test that covers the difficult to get
right parts of Markdown/CommonMark
On Monday, 11 December 2017 at 14:22:37 UTC, Jakob Bornecrantz
wrote:
There are loads of implementations of CommonMark
https://github.com/commonmark/CommonMark/wiki/List-of-CommonMark-Implementations the one I have written is not listed. That covers 1 and 2.
Also Markdown is not a standard, i
On Monday, 11 December 2017 at 14:22:37 UTC, Jakob Bornecrantz
wrote:
And to add more, CommonMark on the other hand has a full spec
written and several test that covers the difficult to get right
parts of Markdown/CommonMark. I'm sure I don't need to tell you
the virtues of a good test suit.
On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright wrote:
On 12/10/2017 6:22 AM, meppl wrote:
I think these are wrong criterias to estimate the value of
commonmark. Commonmark doesn't need to list anyone and doesn't
need to be listed by anyone to be a standard. commonmark is a
standard
On 12/10/2017 6:22 AM, meppl wrote:
I think these are wrong criterias to estimate the value of commonmark.
Commonmark doesn't need to list anyone and doesn't need to be listed by anyone
to be a standard. commonmark is a standard proven by following "facts":
1) whenever a language feature is used
On Sunday, 10 December 2017 at 06:20:43 UTC, Walter Bright wrote:
On 12/9/2017 9:17 PM, meppl wrote:
since commonmark exists, is specified and is compatibale to
many markdown-languages, I claim there is a markdown
standard: http://spec.commonmark.org/
It certainly wants to be the standard, b
On 12/08/2017 05:13 AM, Walter Bright wrote:
I just don't see much of any improvement of markdown over LINK2.
I do.
On 12/9/2017 9:17 PM, meppl wrote:
since commonmark exists, is specified and is compatibale to many
markdown-languages, I claim there is a markdown standard:
http://spec.commonmark.org/
It certainly wants to be the standard, but until most everyone decides to follow
it, it is not. There is n
On Sunday, 10 December 2017 at 01:19:13 UTC, Walter Bright wrote:
On 12/9/2017 12:23 PM, Jacob Carlborg wrote:
On 2017-12-09 02:49, Walter Bright wrote:
This is way overstating the case. Ddoc already supports some
markdown, and some markdown in different ways.
Yes, but I haven't yet seen any
On 12/9/2017 1:05 PM, David Gileadi wrote:
On 12/8/17 6:49 PM, Walter Bright wrote:
On 12/8/2017 7:30 AM, Jacob Carlborg wrote:
Otherwise it will be confusing and very hard to remember which features are
supported with Markdown syntax and which are not.
This is way overstating the case. Ddoc
On 12/9/2017 12:23 PM, Jacob Carlborg wrote:
On 2017-12-09 02:49, Walter Bright wrote:
This is way overstating the case. Ddoc already supports some markdown, and
some markdown in different ways.
Yes, but I haven't yet seen any official documentation saying that Ddoc supports
Markdown syntax.
On 12/9/17 2:25 PM, Adam D. Ruppe wrote:
On Saturday, 9 December 2017 at 21:05:04 UTC, David Gileadi wrote:
For instance, as I've been working on adding Markdown features I was
surprised to discover that DDoc's current support for
backtick-delimited code only works within a single line. Most
i
On Saturday, 9 December 2017 at 21:05:04 UTC, David Gileadi wrote:
For instance, as I've been working on adding Markdown features
I was surprised to discover that DDoc's current support for
backtick-delimited code only works within a single line. Most
implementations I've seen allow it to span
On 12/8/17 6:49 PM, Walter Bright wrote:
On 12/8/2017 7:30 AM, Jacob Carlborg wrote:
Otherwise it will be confusing and very hard to remember which
features are supported with Markdown syntax and which are not.
This is way overstating the case. Ddoc already supports some markdown,
and some ma
On 2017-12-09 02:49, Walter Bright wrote:
This is way overstating the case. Ddoc already supports some markdown,
and some markdown in different ways.
Yes, but I haven't yet seen any official documentation saying that Ddoc
supports Markdown syntax.
--
/Jacob Carlborg
On Fri, Dec 08, 2017 at 05:34:31PM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/8/2017 3:10 AM, Seb wrote:
[...]
> > https://unicode.org/emoji/charts/full-emoji-list.html
>
> Thanks for the link, I didn't know that browsers supported them yet.
>
> If you want to use them, just use the ex
On 12/8/2017 7:30 AM, Jacob Carlborg wrote:
Otherwise it will be confusing and very hard
to remember which features are supported with Markdown syntax and which are not.
This is way overstating the case. Ddoc already supports some markdown, and some
markdown in different ways.
On Fri, Dec 08, 2017 at 05:38:21PM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/8/2017 7:53 AM, Steven Schveighoffer wrote:
> > +1000, I can't imagine why you'd want emoji in your documentation.
>
> No D-Man emoji, sigh.
We should lobby the Unicode Consortium to add it!
T
--
Never st
On 12/8/2017 7:53 AM, Steven Schveighoffer wrote:
+1000, I can't imagine why you'd want emoji in your documentation.
No D-Man emoji, sigh.
On 12/8/2017 3:10 AM, Seb wrote:
On Friday, 8 December 2017 at 10:13:28 UTC, Walter Bright wrote:
On 12/8/2017 1:48 AM, Jacob Carlborg wrote:
* Using emoji
The problem with these is where are the images stored? So no.
Someone thought it's a great idea, to include them into Unicode:
https:/
On Friday, 8 December 2017 at 18:11:56 UTC, Steven Schveighoffer
wrote:
On 12/8/17 12:09 PM, Patrick Schluter wrote:
On Friday, 8 December 2017 at 15:53:41 UTC, Steven
Schveighoffer wrote:
On 12/8/17 7:42 AM, WebFreak001 wrote:
On Friday, 8 December 2017 at 11:10:16 UTC, Seb wrote:
[...]
pl
On 12/8/17 12:09 PM, Patrick Schluter wrote:
On Friday, 8 December 2017 at 15:53:41 UTC, Steven Schveighoffer wrote:
On 12/8/17 7:42 AM, WebFreak001 wrote:
On Friday, 8 December 2017 at 11:10:16 UTC, Seb wrote:
On Friday, 8 December 2017 at 10:13:28 UTC, Walter Bright wrote:
On 12/8/2017 1:48
On Fri, Dec 08, 2017 at 02:13:28AM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/8/2017 1:48 AM, Jacob Carlborg wrote:
[...]
> > * Using emoji
>
> The problem with these is where are the images stored? So no.
Unicode contains emoji blocks, which are increasingly commonly used
nowadays.
B
On Friday, 8 December 2017 at 15:53:41 UTC, Steven Schveighoffer
wrote:
On 12/8/17 7:42 AM, WebFreak001 wrote:
On Friday, 8 December 2017 at 11:10:16 UTC, Seb wrote:
On Friday, 8 December 2017 at 10:13:28 UTC, Walter Bright
wrote:
On 12/8/2017 1:48 AM, Jacob Carlborg wrote:
* Using emoji
Th
On Friday, 8 December 2017 at 16:43:56 UTC, John Gabriele wrote:
If going forward with a rolling your own limited markdown
version, go with a subset of CommonMark.
Sorry, typo, that should be, "consider going with".
On Friday, 8 December 2017 at 10:13:28 UTC, Walter Bright wrote:
On 12/8/2017 1:48 AM, Jacob Carlborg wrote:
> I think we should try to support standard markdown [2]
Unfortunately, there's really no such thing.
Well, the main standardization effort is
[CommonMark](http://commonmark.org/). T
On 12/8/17 7:42 AM, WebFreak001 wrote:
On Friday, 8 December 2017 at 11:10:16 UTC, Seb wrote:
On Friday, 8 December 2017 at 10:13:28 UTC, Walter Bright wrote:
On 12/8/2017 1:48 AM, Jacob Carlborg wrote:
* Using emoji
The problem with these is where are the images stored? So no.
Someone tho
On 2017-12-08 11:13, Walter Bright wrote:
On 12/8/2017 1:48 AM, Jacob Carlborg wrote:
I think links are pretty important, or do you prefer to use Ddoc
macros for that?
I just don't see much of any improvement of markdown over LINK2.
I think we should try to support standard markdown [2]
U
On Friday, 8 December 2017 at 11:10:16 UTC, Seb wrote:
On Friday, 8 December 2017 at 10:13:28 UTC, Walter Bright wrote:
On 12/8/2017 1:48 AM, Jacob Carlborg wrote:
* Using emoji
The problem with these is where are the images stored? So no.
Someone thought it's a great idea, to include them
On Friday, 8 December 2017 at 10:13:28 UTC, Walter Bright wrote:
On 12/8/2017 1:48 AM, Jacob Carlborg wrote:
* Using emoji
The problem with these is where are the images stored? So no.
Someone thought it's a great idea, to include them into Unicode:
https://unicode.org/emoji/charts/full-emo
On 12/8/2017 1:49 AM, Arjan wrote:
Dang! And there you have it: endless complains and issues about the choosen
flavour comming ahead of us now... :-(
Naturally. Just Say No :-)
I would suggest: AsciiDoc! Why?
see:http://ericholscher.com/blog/2016/mar/15/dont-use-markdown-for-technical-docs/
On 12/8/2017 1:48 AM, Jacob Carlborg wrote:
I think links are pretty important, or do you prefer to use Ddoc macros for
that?
I just don't see much of any improvement of markdown over LINK2.
I think we should try to support standard markdown [2]
Unfortunately, there's really no such thing
On Thursday, 7 December 2017 at 10:21:21 UTC, Jacob Carlborg
wrote:
On 2017-12-06 05:11, Walter Bright wrote:
https://help.github.com/articles/basic-writing-and-formatting-syntax/
Anyone interested in picking up the flag?
(I know this has come up before, and I've been opposed to it,
but I've
On 2017-12-08 06:35, Walter Bright wrote:
I dunno. Make a case. There's no backward compatibility necessary, so we
do not have to worry about the two ways of doing lists, for example.
Just '*' will do.
Aside from what Ddoc already does, I'd just stick with:
* Lists
* Nested Lists
* Headings
On 12/7/2017 2:21 AM, Jacob Carlborg wrote:
On 2017-12-06 05:11, Walter Bright wrote:
https://help.github.com/articles/basic-writing-and-formatting-syntax/
Anyone interested in picking up the flag?
(I know this has come up before, and I've been opposed to it, but I've changed
my mind.)
Fina
On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright
wrote:
https://help.github.com/articles/basic-writing-and-formatting-syntax/
I think you'll find it is easier said than done to get sane
output given existing ddoc pages.
My adrdox does some of this special syntax and to maintain
On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright
wrote:
https://help.github.com/articles/basic-writing-and-formatting-syntax/
Anyone interested in picking up the flag?
(I know this has come up before, and I've been opposed to it,
but I've changed my mind.)
Great to hear this! :)
On 2017-12-06 05:11, Walter Bright wrote:
https://help.github.com/articles/basic-writing-and-formatting-syntax/
Anyone interested in picking up the flag?
(I know this has come up before, and I've been opposed to it, but I've
changed my mind.)
Finally :), this is awesome. Should we implement
On 12/5/17 9:11 PM, Walter Bright wrote:
https://help.github.com/articles/basic-writing-and-formatting-syntax/
Anyone interested in picking up the flag?
(I know this has come up before, and I've been opposed to it, but I've
changed my mind.)
I didn't notice anyone pick this up yet. I'm takin
On 12/6/2017 5:24 AM, Adrian Matoga wrote:
This is going to be the right time to deprecate the automatic change of some
words that happen to be parameter names into code. :)
Let's please keep that as a completely separate discussion, as the issue is
orthogonal.
On Wed, Dec 06, 2017 at 02:42:49PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 12/06/2017 01:14 PM, H. S. Teoh wrote:
> > This "feature" has been the source of countless Phobos and dlang.org
> > bugs, leading to time-wasting churn of changing `someword` into
> > `_someword`, just to s
On 12/06/2017 01:14 PM, H. S. Teoh wrote:
This "feature" has been the source of countless Phobos and dlang.org
bugs, leading to time-wasting churn of changing `someword` into
`_someword`, just to suppress the automatic change.
Isn't that controlled via a macro? We should just redefine the macro
On Wed, Dec 06, 2017 at 10:32:38AM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
> On 12/6/17 8:24 AM, Adrian Matoga wrote:
> > On Wednesday, 6 December 2017 at 12:13:56 UTC, Walter Bright wrote:
> > > On 12/5/2017 8:11 PM, Walter Bright wrote:
> > > > (I know this has come up before, and I
On Wednesday, 6 December 2017 at 15:08:53 UTC, David Gileadi
wrote:
On 12/6/17 6:41 AM, Nemanja Boric wrote:
On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright
wrote:
https://help.github.com/articles/basic-writing-and-formatting-syntax/
Anyone interested in picking up the flag?
(I k
On 12/6/17 8:24 AM, Adrian Matoga wrote:
On Wednesday, 6 December 2017 at 12:13:56 UTC, Walter Bright wrote:
On 12/5/2017 8:11 PM, Walter Bright wrote:
(I know this has come up before, and I've been opposed to it, but
I've changed my mind.)
Part of this change of mind was driven by the bit of
On 12/6/17 6:41 AM, Nemanja Boric wrote:
On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright wrote:
https://help.github.com/articles/basic-writing-and-formatting-syntax/
Anyone interested in picking up the flag?
(I know this has come up before, and I've been opposed to it, but I've
c
On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright
wrote:
https://help.github.com/articles/basic-writing-and-formatting-syntax/
Anyone interested in picking up the flag?
(I know this has come up before, and I've been opposed to it,
but I've changed my mind.)
These are great news. W
On Wednesday, 6 December 2017 at 12:13:56 UTC, Walter Bright
wrote:
On 12/5/2017 8:11 PM, Walter Bright wrote:
(I know this has come up before, and I've been opposed to it,
but I've changed my mind.)
Part of this change of mind was driven by the bit of markdown
that Ddoc already supports - th
On 12/6/2017 3:37 AM, Sönke Ludwig wrote:
No problem!
Now, just need someone to step up and do the work. :-/
On 12/5/2017 8:11 PM, Walter Bright wrote:
(I know this has come up before, and I've been opposed to it, but I've changed
my mind.)
Part of this change of mind was driven by the bit of markdown that Ddoc already
supports - the backticks to quote code and auto detection of URLs - and how nice
Am 06.12.2017 um 12:34 schrieb Walter Bright:
On 12/6/2017 1:33 AM, Sönke Ludwig wrote:
This is great news! While I don't have the time to work on this
directly, I can offer vibe.d's Markdown module* (re-licensing as
necessary):
https://github.com/vibe-d/vibe.d/blob/master/textfilter/vibe/text
On 12/6/2017 1:33 AM, Sönke Ludwig wrote:
This is great news! While I don't have the time to work on this directly, I can
offer vibe.d's Markdown module* (re-licensing as necessary):
https://github.com/vibe-d/vibe.d/blob/master/textfilter/vibe/textfilter/markdown.d
Markdown is a strange thing
Am 06.12.2017 um 05:11 schrieb Walter Bright:
https://help.github.com/articles/basic-writing-and-formatting-syntax/
Anyone interested in picking up the flag?
(I know this has come up before, and I've been opposed to it, but I've
changed my mind.)
This is great news! While I don't have the ti
On 12/5/2017 8:37 PM, Mike Parker wrote:
Can you see me jumping up and down over here?
No, but my seismometer is showing some action!
On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright
wrote:
https://help.github.com/articles/basic-writing-and-formatting-syntax/
Anyone interested in picking up the flag?
(I know this has come up before, and I've been opposed to it,
but I've changed my mind.)
Can you see me jumping
We should probably do the opposite.
Build a markdown parser and then have a way to give the output an
understanding of ddoc features.
It will also be usable in other projects ;)
https://help.github.com/articles/basic-writing-and-formatting-syntax/
Anyone interested in picking up the flag?
(I know this has come up before, and I've been opposed to it, but I've changed
my mind.)
87 matches
Mail list logo
