New link syntax
bob at wolfwall.com
Wed Mar 31 15:45:43 EST 2004
On Wed, 2004-03-31 at 21:05, John Gruber wrote:
> Translation is a part of publishing.
> Syntax checking is a part of editing.
> It's very important not to blur those lines.
I don't think I am blurring the lines; I didn't state when and where
Markdown ought to emit errors :) I'm suggesting that it ought to emit
errors in certain circumstances, since I believe that there will be
common, detectable, mistakes - I think we agree that such mistakes are
possible to detect.
> Think of it like a compiler. A programmer needs to see errors and
> warnings before he sends the application off to end users. Why in
> the world would end users want to see them?
I think you're actually making my point for me here. gcc doesn't ship
with a separate 'C checker'; it emits warnings when it detects them.
Markdown is in exactly the same position. Possibly what you mean is that
in some situations (ie., the web) it's more difficult to plug the
compiler into the IDE?
We might be talking at cross purposes here. Imagine you're editing
Markdown in a browser window. What I'm suggesting is some kind of
document to (e.g.) /cgi-bin/check-markdown.pl. The difference between
the two scripts would merely be that check-markdown.pl passes a
"--check-document" flag or something, which makes it output errors
instead of HTML, an the script presents those to the editor of the doc.
The alternative is that you basically build up a second tool attempting
to be bug-for-bug compatible with the syntax of the original tool, or a
fair proportion of it. I would think it would be easier just to have a
flag on one tool, and not duplicate the syntax parser.
(Of course, there may also be other concerns for a checker - perhaps you
That's separate to what I'm talking about above, and the arguments
for/against are probably mostly different; maybe you can't plug the main
parser into the editor nicely enough or some similar implementation
More information about the Markdown-discuss