On 4 Jun 2020, at 9:22, Christian Perry wrote:
It wouldn't have to break anything to update MD syntax: simply present
it
as a new version, and note that certain conventions from old version
are
being deprecated. Put it on LTS and give the industry 15 years to
adapt
(I'm serious about this).
On 4 Jun 2020, at 5:29, Christian Perry wrote:
To move the conversation forward, I propose an alternative markdown
italicized syntax: *bounding double exclamation marks*.
For example: Huzzah, we can !!finally!! use bounding asterisks again!
*celebrates with much rejoicing*
The widespread
If you find someone’s post(s) inappropriate then tell them in private!
I realize the irony in sending this to the list, but this isn’t the
first thread with a dozen posts just bikcering about non-markdown
related stuff.
On 21 Nov 2011, at 21:00, Christian Sciberras wrote:
Yay! Never mind
On 20 Oct 2011, at 15:20, Sherwood Botsford wrote:
[…] If agreement is reached, then the group looks at variants 6,7,8,9 and
inquires if they would like to join in this effort.
On 19 Oct 2011, at 02:27, John MacFarlane wrote:
That said, if I were designing a non-markup language from scratch,
On 5 Nov 2010, at 10:18, Jan Erik Moström wrote:
I don't think you can get Gruber to bless an extension.
Indeed — this has come up before. Gruber used ‘.text’ at that time.
One suggestion I liked was ‘.mtext’ since it stresses the readability
of the file.
I use ‘.mdown’ myself — I’d
On 3 May 2010, at 09:42, Mathias wrote:
1. Test Suite: Is there anything more than John Grubers test suite
that you know off? Maybe a good, large file for benchmarking? I'd
like to compare pegdowns performance to some other implementations.
I could also run the original test suite a few
On 2 May 2010, at 14:01, Aristotle Pagaltzis wrote:
[…] you want to filter out HTML tags […]
[…] And it’s not impossible to write a 100% solid filter if you use
a *white*list applied to a real HTML parser.
Not sure what you mean by “real HTML parser”.
One thing to watch out for is improper
On 1 May 2010, at 11:45, Louis-David Mitterrand wrote:
Is markdown a good language to use in a web forum application? How
does it compare to bbcode in features and ease-of-use for non-
technical users?
One advantage of BBCode is that it has nothing to do with HTML. It is
its own language
On 22 May 2008, at 08:10, Aristotle Pagaltzis wrote:
[...]
Optional features are dangerous and impede interoperability.
Everyone who ever thinks about chipping in on the design of
a spec should read [section 5 of RFC 3339][1]. [...]
I love how it says:
[...] A format which includes
On 20 Apr 2008, at 00:28, Sherwood Botsford wrote:
[...]
Suppose that markdown was clever enough to reference an external
file (in .markdownrc of course) for the resolution of LABEL.
Here’s a simple shell script to convert all markdown to HTML and using
a shared references file:
cd
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
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
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
On 18 Feb 2008, at 23:59, Andrea Censi wrote:
[...]
In a nutshell: given that Markdown.pl (and straight ports of it) do
processing using multiple passes of regex/replace, you cannot find a
syntax that captures Markdown.pl's behavior exactly.
I did a rule-based implementation which I have
On 11 Feb 2008, at 02:41, John Gabriele wrote:
[...]
PmWiki is php-based and is pretty full-featured. By default it uses
regular files instead of mysql (last time I looked). There's an
extension for it to use Markdown[^1], but I haven't tried it.
There are actually two -- I tried both, and
On 7 Feb 2008, at 00:53, Thomas Nichols wrote:
[...] Of course, this argument is moot if there's no interest in
having browsers handle markdown intelligently [...]
Browsers are not the only applications using mime-types, and I do see
other mime-type-using applications benefit from a
On Aug 27, 2007, at 11:02 PM, Eric Astor wrote:
[...]
Well - has anyone else looked into ANTLR 3.0 at all? The LL(*)
grammar language it uses (an EBNF) allows for full backtracking
support, and unspecified lookahead as far as necessary. It's fairly
well-optimized, as I understand it,
On Sep 3, 2007, at 1:28 PM, Michel Fortin wrote:
[...] Take a look at this instead:
int[1][2] one_by_two_array;
Sure, a code block or span should be used here, but I think
*requiring* the code block or span here in order to not screw up
the end result isn't the right path to take
On Aug 15, 2007, at 5:24 PM, Michel Fortin wrote:
This micro-benchmark gives us a lower running time for a parser that
relies on the constructs tested in the benchmark. So is the lower
running time really that bad? Well, I changed the premises slightly
just to show that the lower running
On Aug 27, 2007, at 6:42 PM, Michel Fortin wrote:
I'm totally not convinced that creating a byte-by-byte parser in
Perl or PHP is going to be very useful.
The key here is really having clearly defined state transitions.
I'm not sure what you mean by that in relation to what I wrote above.
On Aug 27, 2007, at 10:35 PM, Michel Fortin wrote:
Personally, as I have said before, the back-tick rules are
confusing (when you want to include a back-tick in the code) and
we might be better off by just defining some simpler rules.
I don't find them confusing, but perhaps it's only
On Aug 14, 2007, at 9:45 AM, Michel Fortin wrote:
[...] Your interpretation of the syntax would require that:
(mine) ` `` `
(your's) ``` `` ```
Well, showing that my interpretation of Gruber’s writings leads to a
lot of redundant back-ticks (in a
On Aug 14, 2007, at 9:41 AM, Michel Fortin wrote:
[...]
I agree that the syntax needs to be defined more clearly.
I am glad that we are finally reaching agreement on this. You may not
recall, but a year ago you asked me: “is it so much important that
these border cases be consistent
On Aug 13, 2007, at 10:20 AM, Michel Fortin wrote:
Le 2007-08-12 à 23:23, Allan Odgaard a écrit :
I would have expected it to see first two back-ticks, then scan
forward until another two back-ticks are seen (since the open-
token defines the close-token) and thus give this output
I forked the topic, since this is an (interesting) topic of its own,
not really related to the interpretation of code-spans.
On Aug 13, 2007, at 10:20 AM, Michel Fortin wrote:
[...] I know most Markdown parsers do not follow conventional
parser wisdom, but IMO this is also the
On Aug 9, 2007, at 9:57 AM, Michel Fortin wrote:
[...] I'm sensible to the idea of having a way to do automatic
updates. Someone asked me recently for a PHP Markdown package
suitable for the PEAR installer; would that be helpful?
I am not familiar with this installer, I will look at it
On 4. Aug 2007, at 05:37, Michel Fortin wrote:
[...]
Download page:
http://www.michelf.com/projects/php-markdown/
Assuming you keep the source under svn control here’s a request for
exposing that.
That way we can just “svn up” or “svn switch «tag»” to update.
On 9. May 2007, at 21:42, John Gruber wrote:
+ Now supports URLs containing literal parentheses, such as:
http://en.wikipedia.org/wiki/WIMP_(computing)
Such parentheses may be arbitrarily nested, but must be
balanced.
This breaks markup such as:
See
Seeing how no-one should send application/xhtml+xml to the browser
[1], and development of the HTML standard is again happening [2], it
would make sense to have Markdown.pl default to HTML tags.
Maybe too late to change a default though.
How does PHP Markdown and other implementations deal
On 22. Nov 2006, at 21:48, Waylan Limberg wrote:
Considering those requirements, I would strongly recommend PMWiki.org.
I know a markdown extension exists for it, although last I knew it was
incomplete, but that was some time ago.
I am using PMWiki with version 1.1 of the Markdown extension,
On 20. Oct 2006, at 06:37, Jacob Rus wrote:
But I posit that this is really a non-issue, as there is almost no
use for multiple consecutive code blocks with no commentary in
between [...]
Agreed. If new syntax is going to be introduced, why not do some of
the stuff which there is
On 18. Oct 2006, at 15:19, Waylan Limberg wrote:
For whatever it is worth, both perl and php have this behavior while
python gives the expected output. I'd certainly say it is a bug [...]
In that case one could argue that there are a few related bugs, e.g.
in the following the “much further
Greedy matching is generally more efficient (so it’s a good idea to
use it when possible), but the reason it is faster is because of
changed semantics.
Take this string:
foo...«lots of text»...bar...«lots more text»...end
If we match it against ‘foo.*bar’ the regexp engine will first
On 10. Oct 2006, at 00:20, Fletcher T. Penney wrote:
But wouldn't it make sense to try and have a consistent file
extension for Markdown files for those who want something more
specific than .txt or .text?
Definitely!
In addition to the “out of the box” support for the file opened in
On 10. Oct 2006, at 03:33, Michel Fortin wrote:
[...] I'm not sure how high is that risk for all character
combinaisons, but it obviously is less problematic than the current
behaviour is to UTF-8.
This report http://www.ifi.unizh.ch/mml/mduerst/papers/PDF/IUC11-
UTF-8.pdf talks about
On 8. Oct 2006, at 19:24, John Gruber wrote:
I feel strongly now that this was a mistake, and that the rules
should be tightened such that all (or nearly all -- there may be
worthwhile exceptions I haven't considered) block level constructs
must be both preceded and succeeded by a blank
On 7. Oct 2006, at 06:27, Allan Odgaard wrote:
Replying to myself here, as I didn’t get any other replies than the
latest from A. Pagaitzis (so checked the archive).
Noticed the patterns for setext style headings are:
^(.+)[ \t]*\n=+[ \t]*\n+
Here (.+) is greedy and thus will match
On 5. Oct 2006, at 17:17, Trevor Jim wrote:
I've put up a new version that handles relative links properly
and fixes a few bugs.
Neat! I noticed a few problems:
* it seems to make excessive use of escapes. E.g. each number
followed by a period has the period escaped
* special characters
On 2/8/2006, at 1:44, Michel Fortin wrote:
[...] For an item to contain block-level content
I assume this rule applies only to *list* items? Given that e.g.
block quoted text does not show the problem I demonstrated.
it must be separated by a blank line from the previous or the next
On 30/7/2006, at 22:34, Michel Fortin wrote:
[...] I'd like to point out that in my view John's implementation
is already doing tokenization in some form [...]
Well, this here [1] is what people generally refer to when speaking
of tokenizing input.
[...] For example, let's create a link
40 matches
Mail list logo
