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 here is
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
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 formatting is
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
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
think
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 question. Here's a
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 very good
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 routines
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. strongemhello/em, sailor/strong
2. strong*hello*, sailor/strong
3.
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
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 markdown-discuss@six.pairlist.net 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
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 right
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
do *not*
In article [EMAIL PROTECTED],
John Fraser markdown-discuss@six.pairlist.net 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.
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
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
In article [EMAIL PROTECTED],
John Fraser markdown-discuss@six.pairlist.net 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
* [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 what intent
* 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 this:
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). What
david parsons wrote:
In article [EMAIL PROTECTED],
Seumas Mac Uilleachan markdown-discuss@six.pairlist.net wrote:
david parsons wrote:
In article [EMAIL PROTECTED],
markdown-discuss@six.pairlist.net wrote:
however, implementers can reach agreement easily,
by leaving
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
* [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 agree
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
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
In article [EMAIL PROTECTED],
markdown-discuss@six.pairlist.net 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
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
31 matches
Mail list logo
