a specification will _eventually_ be used, by someone,
to tell the user they are doing things "wrong", won't it?
and doesn't that turn markdown's genesis upside-down?
heck, next thing you know we'll be telling them to r.t.f.m.
i would prefer that implementers get more sophisticated
about teasing
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-03-03 07:00]:
> i would prefer that implementers get more sophisticated
> about teasing out the user's intent in "ambiguous" cases.
If every implementor teases a different intent out the same
document, the user loses.
Is it possible for everyone to ag
Le 2008-03-03 à 0:55, [EMAIL PROTECTED] a écrit :
a specification will _eventually_ be used, by someone,
to tell the user they are doing things "wrong", won't it?
Well, that's not the specification I intend to do. All inputs are
right in Markdown; there is no such thing as "invalid" or "non-
Le 2008-03-03 à 6:36, Aristotle Pagaltzis a écrit :
Why then does the fallacious argument that a spec would represent
a loss for the user continue?
Some people have proposed before that some constructs may not be
outlawed, that syntax rules should be changed, that Markdown is either
too cl
well, i had said i wouldn't reply on this, but i think that
this post will still manage to be productive. i hope so...
***
aristotle said:
>If every implementor teases a different intent
>out the same document, the user loses.
well, yes. but that's pretty obvious, isn't it?
there n
> I don't think Markdown should be changed, we just need a spec to avoid
> each implementation from implementing "cleverness" in incompatible
> manners. Let's specify exactly how things *are* parsed now, minus the
> bugs.
I agree. Let's try to avoid any serious changes. To the extent that
th
In article <[EMAIL PROTECTED]>,
wrote:
>however, implementers can reach agreement easily,
>by leaving users out in the cold, brushing them off
>with a "you will need to follow the spec" which seems
>-- if i understand markdown's cornerstone correctly --
>to be outside gruber's comfort range for
david parsons wrote:
In article <[EMAIL PROTECTED]>,
wrote:
however, implementers can reach agreement easily,
by leaving users out in the cold, brushing them off
with a "you will need to follow the spec" which seems
-- if i understand markdown's cornerstone correctly --
to be outside grube
In article <[EMAIL PROTECTED]>,
Seumas Mac Uilleachan wrote:
>david parsons wrote:
>> In article <[EMAIL PROTECTED]>,
>> wrote:
>>> however, implementers can reach agreement easily,
>>> by leaving users out in the cold, brushing them off
>>> with a "you will need to follow the spec" which seem
On 4 Mar 2008 10:15:10 -0800, david parsons <[EMAIL PROTECTED]> wrote:
>
>I'm not surprised when
>
> 1986. What a great season.
>
>generates a list item, because the existing spec tells me that
>
>``[...]a _number-period-space_ sequence at the beginning of a line[...]''
>
>will tr
> I think what is trying to be said here is that in creating the spec you
> can't lose the original focus of what Markdown is all about. Users
> (such as myself) don't really care that much about how the html is
> generated (breaks and explicit paragraphing are the domain of the
> parser). Wh
david parsons wrote:
In article <[EMAIL PROTECTED]>,
Seumas Mac Uilleachan wrote:
david parsons wrote:
In article <[EMAIL PROTECTED]>,
wrote:
however, implementers can reach agreement easily,
by leaving users out in the cold, brushing them off
with a "you will need to f
Le 2008-03-04 à 13:15, david parsons a écrit :
But what's the intent of ***hello*, sailor** ?
Should it produce
1. hello, sailor
2. *hello*, sailor
3. *hello*, sailor
4. ***hello, sailor
5. ***hello*, sailor**
6. hello, sailor
7. hello, sailor (which makes baby XML
Le 2008-03-04 à 21:47, Seumas Mac Uilleachan a écrit :
david parsons wrote:
And how about _cut here_ ?
This is a problem. Anything more than 4 _ per side does not render
but with 4 it does (in PHP) if you have cut here are you
expecting it to be converted to cut
On Tue, Mar 4, 2008 at 10:08 PM, Michel Fortin
<[EMAIL PROTECTED]> wrote:
> Le 2008-03-04 à 13:15, david parsons a écrit :
>
>
> > But what's the intent of ***hello*, sailor** ?
> >
> > Should it produce
> >1. hello, sailor
> >2. *hello*, sailor
> >3. *hello*, sailor
> >
Michel Fortin wrote:
Le 2008-03-04 à 21:47, Seumas Mac Uilleachan a écrit :
david parsons wrote:
And how about _cut here_ ?
This is a problem. Anything more than 4 _ per side does not render
but with 4 it does (in PHP) if you have cut here are you
expecting it to
Steve Hoelzer wrote:
On Tue, Mar 4, 2008 at 10:08 PM, Michel Fortin
<[EMAIL PROTECTED]> wrote:
Le 2008-03-04 à 13:15, david parsons a écrit :
> But what's the intent of ***hello*, sailor** ?
>
> Should it produce
>1. hello, sailor
>2. *hello*, sailor
>3. *hello*, sai
On Mar 4, 2008, at 11:09 PM, Michel Fortin wrote:
Yeah, the list implementation in Markdown.pl and PHP Markdown
doesn't follow the at all the little of a spec we have now. I've
been thinking about rewriting the list parser in PHP Markdown, but
I'm wondering what to do to not suddenly change
In article <[EMAIL PROTECTED]>,
Seumas Mac Uilleachan wrote:
> Currently (which is strange)
>the first line in my example has three spaces and is a first level list.
>The next line has only two but becomes a **second level** list.
I believe that the markdown you're using is being overly agg
> A list item's parent is the most recent list item whose bullet is indented
> less than its own. If there's no such parent, then the item belongs to a
> root-level list.
>
> http://six.pairlist.net/pipermail/markdown-discuss/2008-March/001076.html
>
> Is there any case where this doesn't do the
On Wed, Mar 5, 2008 at 10:53 AM, John Fraser <[EMAIL PROTECTED]> wrote:
> A list item's parent is the most recent list item whose bullet is
> indented less than its own. If there's no such parent, then the item
> belongs to a root-level list.
>
> http://six.pairlist.net/pipermail/markdown-disc
> My only other concern is when stepping back out of the nesting.
> Suppose we have the following list:
>
> * no spaces - level 1
> * 4 spaces - level 2
> * 6 spaces - level 3
> * 2 spaces - level 1.5 ???
>
> Obviously, that would break. But what's the best way to handle that? I
>
In article <[EMAIL PROTECTED]>,
John Fraser wrote:
>
>A list item's parent is the most recent list item whose bullet is
>indented less than its own. If there's no such parent, then the item
>belongs to a root-level list.
>
>http://six.pairlist.net/pipermail/markdown-discuss/2008-March/001076
On Wed, Mar 5, 2008 at 1:46 PM, Vinay Augustine <[EMAIL PROTECTED]> wrote:
> > My only other concern is when stepping back out of the nesting.
> > Suppose we have the following list:
> >
> > * no spaces - level 1
> > * 4 spaces - level 2
> > * 6 spaces - level 3
> > * 2 spaces
Waylan Limberg wrote:
{snip}
My only other concern is when stepping back out of the nesting.
Suppose we have the following list:
* no spaces - level 1
* 4 spaces - level 2
* 6 spaces - level 3
* 2 spaces - level 1.5 ???
Obviously, that would break. But what's the best way to handle
On Mar 5, 2008, at 2:40 PM, Waylan Limberg wrote:
On Wed, Mar 5, 2008 at 1:46 PM, Vinay Augustine <[EMAIL PROTECTED]>
wrote:
* no spaces - level 1
* 4 spaces - level 2
* 6 spaces - level 3
* 2 spaces - level 1.5 ???
With the rule just proposed, wouldn't the last line simply be le
On Mar 5, 2008, at 2:38 PM, david parsons wrote:
When I write a really long list,
* sometimes, after a particularly long and
detailed list item, I'll lose track of the
exact indentation and
* add one too many spaces to the leading
indent.
so it would be bad if th
In article <[EMAIL PROTECTED]>,
John Fraser wrote:
>
>On Mar 5, 2008, at 2:38 PM, david parsons wrote:
>> When I write a really long list,
>>
>>* sometimes, after a particularly long and
>> detailed list item, I'll lose track of the
>> exact indentation and
>> * add one too
On Mar 5, 2008, at 2:38 PM, david parsons wrote:
When I write a really long list,
* sometimes, after a particularly long and
detailed list item, I'll lose track of the
exact indentation and
* add one too many spaces to the leading
indent.
so it would be bad if th
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-03-03 23:45]:
> > Is it possible for everyone to agree in all cases about how
> > the user’s intent should be teased out? Clearly it is
> > conceivable that enough effort could be made to write all
> > agreements down.
> >
> > And if you write down wha
* Michel Fortin <[EMAIL PROTECTED]> [2008-03-05 05:10]:
> A better question is what to do with this:
>
> *hello **dear* boy**
That’s a very good question. Here’s a counterquestion: what does
a human reader see in that text? Based on the visual apperance I
think I would make it translate to thi
Aristotle Pagaltzis wrote:
* Michel Fortin <[EMAIL PROTECTED]> [2008-03-05 05:10]:
A better question is what to do with this:
*hello **dear* boy**
That’s a very good question. Here’s a counterquestion: what does
a human reader see in that text? Based on the visual apperance I
thin
On Thu, Mar 6, 2008 at 9:39 AM, Seumas Mac Uilleachan <[EMAIL PROTECTED]> wrote:
> Aristotle Pagaltzis wrote:
> > * Michel Fortin <[EMAIL PROTECTED]> [2008-03-05 05:10]:
> >
> >> A better question is what to do with this:
> >>
> >> *hello **dear* boy**
> >>
> >
> > That's a very good qu
Waylan Limberg wrote:
On Thu, Mar 6, 2008 at 9:39 AM, Seumas Mac Uilleachan <[EMAIL PROTECTED]> wrote:
Aristotle Pagaltzis wrote:
> * Michel Fortin <[EMAIL PROTECTED]> [2008-03-05 05:10]:
>
>> A better question is what to do with this:
>>
>> *hello **dear* boy**
>>
>
> That's a ve
In article <[EMAIL PROTECTED]>,
Steve Hoelzer wrote:
>On Tue, Mar 4, 2008 at 10:08 PM, Michel Fortin
><[EMAIL PROTECTED]> wrote:
>> Le 2008-03-04 à 13:15, david parsons a écrit :
>> > But what's the intent of ***hello*, sailor** ?
>So, the question is: Would you ever see **mismatched *aster
> Maybe what is needed is some kind of syntax checker to run the source
> through to point out to users where there are errors and/or confusing
> markup. This could be a separate function from markdown itself, like
> markdown-lint, or a separate output option of markdown. A separate
> function
aristotle said:
>The reasoning I outlined in questions
>[I've taken the liberty to re-insert the quotation you elided]
>shows that the premises do not support the argument.
your questions created a straw-man.
i agreed that the exact same input should create the same output.
it'd be
On Thu, Mar 6, 2008 at 12:22 PM, <[EMAIL PROTECTED]> wrote:
>
> the situation that's troubling is where one set of input is clear,
> while another set of similar-but-not-identical input leads to
> an interpretation that is _different_ yet still _equally-clear_,
> but you can't easily write rou
> > *hello **dear* boy**
>
> That's a very good question. Here's a counterquestion: what does
> a human reader see in that text?
When I try to look at this with my normal-person eye, what I see here
is incorrect markup, which I then want to leave it as is and move on.
When I look at it with
Hi Yuri, Weylan and Seumas,
* Yuri Takhteyev <[EMAIL PROTECTED]> [2008-03-07 08:50]:
> > > *hello **dear* boy**
> >
> > That's a very good question. Here's a counterquestion: what
> > does a human reader see in that text?
>
> When I try to look at this with my normal-person eye, what I
> see
On Mar 7, 2008, at 2:45 AM, Yuri Takhteyev wrote:
*hello **dear* boy**
That's a very good question. Here's a counterquestion: what does
a human reader see in that text?
When I try to look at this with my normal-person eye, what I see here
is incorrect markup, which I then want to leave it
On Mar 7, 2008, at 5:17 AM, Aristotle Pagaltzis wrote:
Hi Yuri, Weylan and Seumas,
* Yuri Takhteyev <[EMAIL PROTECTED]> [2008-03-07 08:50]:
*hello **dear* boy**
That's a very good question. Here's a counterquestion: what
does a human reader see in that text?
When I try to look at this w
On Fri, Mar 7, 2008 at 5:17 AM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote:
>
> > To me, that is an important factor that seems to be ignored by
> > some here. Sometimes, IMO, the best thing to do is to pass the
> > markup through as literal text and give the author a clue that
> > his forma
joseph said:
>On a constructive tip: What we're trying to do is
>design a perspective, by specifying what markdown does now,
>from which implementations of markdown can
>consistently interpret the same input.
and, if you will allow me to offer a constructive tip to _you_,
i'd s
44 matches
Mail list logo
