On 5 Mar 2008, at 05:02, Michel Fortin wrote:
[big explanation]
So you're basically using a line by line approach.
Yes, seeing how the block-level nesting stuff affects things “line by
line”, this seems like the best approach :)
I was thinking about that as a possibility for parsing block
On Tue, Mar 4, 2008 at 8:02 PM, Michel Fortin <[EMAIL PROTECTED]> wrote:
>
> I'm not sure what's the problem with horizontal rules in blockquotes.
> I've tried many variations of: ...
trying to reproduce this on the df Markdown dingus lead to a weird
result. Here's the input:
> test
>
an
Le 2008-03-04 à 0:49, Allan Odgaard a écrit :
On 3 Mar 2008, at 13:30, Michel Fortin wrote:
[...]
1. A regexp that makes the parser enter the context the rule
represents (e.g. block quote, list, raw, etc.).
2. A list of which rules are allowed in the context of this rule.
3. A regexp for le
On 3 Mar 2008, at 13:30, Michel Fortin wrote:
[...]
1. A regexp that makes the parser enter the context the rule
represents (e.g. block quote, list, raw, etc.).
2. A list of which rules are allowed in the context of this rule.
3. A regexp for leaving the context of this rule.
4. A regexp whi
On Mar 3, 2008, at 3:36 PM, Andrea Censi wrote:
I didn't know what packrat was, so I googled it. It looks interesting:
from what I understand, it's a more user-friendly way of specifying
languages.
Here's a good link, if anyone else is interested:
http://pdos.csail.mit.edu/~baford/packrat/
Sor
> Since I'm doing something packrat-ish, I'm hoping I can use lookahead
> to keep the rules from exploding.
I didn't know what packrat was, so I googled it. It looks interesting:
from what I understand, it's a more user-friendly way of specifying
languages.
Here's a good link, if anyone else is
On Mar 3, 2008, at 7:30 AM, Michel Fortin wrote:
Allan Odgaard wrote:
4. A regexp which is pushed onto a stack when entering the context of
this rule, and popped again when leaving this rule.
The fourth item here is really the interesting part, because it is
what made Markdown nesting work (99
Allan Odgaard wrote:
Though without changing a lot of edge-case behavior, I find it hard
to see Markdown using such rule-based implementation, so personally
I am favoring a new Markdown-inspired language.
For my part, I'm currently trying to specify parsing rules Markdown
Extra, and make
* Yuri Takhteyev <[EMAIL PROTECTED]> [2008-03-01 00:05]:
> 2. As Thomas suggested, we should first reach some agreement as
> to what if anything needs to change from the original Markdown
> or how the "holes" are to be filled. _Then_ try writing a
> grammar. I suggest that we do this first part in
In article <[EMAIL PROTECTED]>,
Allan Odgaard wrote:
>
>On 1 Mar 2008, at 19:19, David Parsons wrote:
>
>>> I agree that Markdown needs to be defined unambiguously, but I don't
>>> think that's feasible with plain English [...]
>>
>>I'm not so sure about this. I managed to write a markdown
>
On 1 Mar 2008, at 19:19, David Parsons wrote:
I agree that Markdown needs to be defined unambiguously, but I don't
think that's feasible with plain English [...]
I'm not so sure about this. I managed to write a markdown
implementation without using anything other than the daring
fir
In article <[EMAIL PROTECTED]>,
John Fraser wrote:
>On Mar 1, 2008, at 1:19 PM, david parsons wrote:
>>> I agree that Markdown needs to be defined unambiguously, but I don't
>>> think that's feasible with plain English in the loop. For something
>>> as complex and flighty as Markdown, we need wo
On Mar 1, 2008, at 1:19 PM, david parsons wrote:
I agree that Markdown needs to be defined unambiguously, but I don't
think that's feasible with plain English in the loop. For something
as complex and flighty as Markdown, we need working code.
I'm not so sure about this. I managed to writ
I think many of Michel's points are quite reasonable. Given that we
agree on many parts, how about we start off with those things we agree
on and deal with other issues later. Specifically, I suggest that we
start with hammering out the "macro" part of "Level 1" of the spec.
I.e., let's not worry
In article <[EMAIL PROTECTED]>,
John Fraser wrote:
>
>On Feb 29, 2008, at 10:13 AM, Michel Fortin wrote:
>
>> I think the syntax needs to be defined unambiguously, not
>> necessarily as a formal grammar, but certainly not with code either.
>> My idea, currently, is to write a parsing procedur
I'm going to comment both on Yuri and Waylan's message here.
Le 2008-03-01 à 0:31, Waylan Limberg a écrit :
On Fri, Feb 29, 2008 at 6:04 PM, Yuri Takhteyev
<[EMAIL PROTECTED]> wrote:
Since Joe called for procedural suggestion, here is what I think we
should do:
1. First, I think there were
Well, if its going to happen, this will probably make it happen.
Further thoughts below:
On Fri, Feb 29, 2008 at 6:04 PM, Yuri Takhteyev <[EMAIL PROTECTED]> wrote:
> Since Joe called for procedural suggestion, here is what I think we should do:
>
> 1. First, I think there were valid concerns abou
On Fri, Feb 29, 2008 at 6:18 PM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote:
>
[snip]
Thanks Aristotle. You bring up may good points which I will not argue
with. That post was meant to generate conversation and you, among
others bit the bait (although you may have bit a little harder). These
ar
On Fri, Feb 29, 2008 at 3:04 PM, Yuri Takhteyev <[EMAIL PROTECTED]> wrote:
> Since Joe called for procedural suggestion, here is what I think we should do:
> 1. ...
> 2. ...
Yuri's suggestion looks reasonable to me.
--
Andrea Censi
PhD student, Control & Dynamical Systems, Caltech
http://www.cd
* Waylan Limberg <[EMAIL PROTECTED]> [2008-02-29 17:00]:
> As implementors, we want a strict spec because it's easier to
> implement, but that does not always result in easier to read
> and/or write.
You have “strict” and “simplistic” confused. If the spec for the
syntax is rigorous that does not
Since Joe called for procedural suggestion, here is what I think we should do:
1. First, I think there were valid concerns about whether it would be
ok for us to come up with a spec and call it "Markdown 2.0". I
suggest we put the question of naming aside. Once we agree on a spec,
we'll ask for
Joseph Lorenzo Hall wrote on 2008/02/29 17:14:
On Fri, Feb 29, 2008 at 8:52 AM, Thomas Nichols <[EMAIL PROTECTED]> wrote:
Having a spec/ruleset/syntax definition seems an admirable goal; does
this necessarily imply that, for example, you should not be able to
begin a list item with zero to
On Fri, Feb 29, 2008 at 11:59 AM, Yuri Takhteyev <[EMAIL PROTECTED]> wrote:
>
> Well, except that people use it for blogs and wikis and they need some
> of those extra features, and if we don't agree on some of them (like
> definition lists and tables) then we end up with a hundred different
>
> Personally, some of the "holes" in the current syntax rules are
> actually the "features" that makes this statement true. As
> implementors, we want a strict spec because it's easier to implement,
> but that does not always result in easier to read and/or write.
I don't see how ambiguity of
On Fri, Feb 29, 2008 at 12:14 PM, Joseph Lorenzo Hall <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 29, 2008 at 8:52 AM, Thomas Nichols <[EMAIL PROTECTED]> wrote:
> >
> > Having a spec/ruleset/syntax definition seems an admirable goal; does
> > this necessarily imply that, for example, you should n
On Fri, Feb 29, 2008 at 8:52 AM, Thomas Nichols <[EMAIL PROTECTED]> wrote:
>
> Having a spec/ruleset/syntax definition seems an admirable goal; does
> this necessarily imply that, for example, you should not be able to
> begin a list item with zero to three spaces, at your discretion? This
> se
On 29 Feb 2008, at 16:52, Thomas Nichols wrote:
Cases in point:
* Feynman
* Dirac
* Bohr
without thinking about inserting an extra line before the list to
ensure that it gets correctly processed, aligning asterisks with
zero indent so they get correctly processed, yada yada. Part of the
Waylan Limberg wrote on 2008/02/29 15:56:
With all this discussion about evolving the spec, I think we want to
remember the philosophy behind Markdown to begin with. Go re-read the
Overview[1] of the syntax rules.
... snip ...
Take the discussion a short time ago on this list regarding w
On Fri, Feb 29, 2008 at 10:56 AM, Waylan Limberg <[EMAIL PROTECTED]> wrote:
> That's not to say that there are no valid arguments to add additional
> syntax, but the arguments for those new rules would need to be very
> convincing.
Just wanted to note that this does not mean that I'm opposed to
On Feb 29, 2008, at 10:13 AM, Michel Fortin wrote:
I think the syntax needs to be defined unambiguously, not
necessarily as a formal grammar, but certainly not with code either.
My idea, currently, is to write a parsing procedure which is easy to
read and implement in various ways, using a
I wholeheartedly agree. The main attractions of Markdown to me are:
1. It is easy to read
I use Markdown for personal info and stuff, then convert and read in
a browser. But for me it is ALSO important to be able to easily read the
original source. That is where Markdown excels over the ot
With all this discussion about evolving the spec, I think we want to
remember the philosophy behind Markdown to begin with. Go re-read the
Overview[1] of the syntax rules.
[1]: http://daringfireball.net/projects/markdown/syntax#overview
As the very first line says:
> Markdown is intended to be a
Le 2008-02-29 à 3:49, Yuri Takhteyev a écrit :
Anyway, a spec for Markdown Extra would contain a spec for Markdown
as
well, wouldn't it?
I think the whole enterprise would be a lot more valuable, if we
produce a combined spec, which would be self-contained, and call it
Markdown 2.0.
I also
> Anyway, a spec for Markdown Extra would contain a spec for Markdown as
> well, wouldn't it?
I think the whole enterprise would be a lot more valuable, if we
produce a combined spec, which would be self-contained, and call it
Markdown 2.0.
I don't think we necessarily need a formal grammar. W
34 matches
Mail list logo
