http://qs1969.pair.com?node_id=503667

I love the "very much like HTML" syntax the Monastery uses for creation of nodes, and I'd never want to eliminate it. However, as the proud owner of a WordPress site, I have fallen in love with Markdown.

I propose that Markdown be considered for inclusion on PerlMonks. It is already Perl, so cleaning it up and putting it into whatever code pre-processes nodes already shouldn't be a huge effort. Also, since it is designed to ignore things that look like HTML, I strongly suspect that implementing it wouldn't break anything about our current node-interpolation stuff.

However, it would have some pretty nice gains. Namely, allowing people to concentrate more on writing the post than formatting (I hate having to remember those paragraph tags), and having posts by newbies be formatted much more DWIMmishly (because they neglect paragraph tags a lot). Since it allows a hybrid of HTML (and would probably just as easily allow existing Monastery syntax) and its own syntax, users could easily choose to use Markdown syntax where it saves time (like using *this* for emphasis), and the usual Monastery markup where it makes more sense (like code or spoiler tags) in the same node

It seems my request to join the pmdevils has been ignored, or I'd be submitting a patch instead of a request, but things being what they are: what say my fellow Monasterians to Markdown?

<-radiant.matrix->
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
"In any sufficiently large group of people, most are idiots" - Kaa's Law

Replies are listed 'Best First'.
Re: Markdown syntax useful to the Monestary?
by saskaqueer (Friar) on Oct 28, 2005 at 15:48 UTC

    I'll have to be one of the first to oppose the idea. Looking at the syntax for the system, it just looks plain ugly to me. There are times I wish to use asterisks in regular text; if those start being translated into emphasis tags, I will be disappointed. Plus, what kind of syntax is [my homenode](/?node_id=340501) for linking? [saskaqueer|my homenode] beats that out anyday (it also beats out [my homenode](saskaqueer) if it would be possible to get it working as such).

    How hard is it to remember <p> tags for paragraphs? I can't stand forums that autoformat text for you (ie: one RETURN key equals one <br /> tag). It's even worse when they combine html with autoformating -- where you wind up with huge gaps of space between paragraphs if you use <p> tags and separate blocks with newlines (as I do here on pm).

    Things work very well here; a lot of work has gone into making perlmonks's formatting/coding specs work as well as they do. Don't mess with them. Of course, if this madness should make it through, I have high hopes that this Markdown system would of course not be turned on by default and would only be accessible via an option in user settings. But of course, my ability to see into the future has shown me that I have nothing to worry about :)

      If this were implemented as I envision, then you wouldn't have to use the markdown methodology, you could just use the monastic style. AFAICT, Markdown parsing ignores something that's just in square brackets, so it would leave [radiantmatrix] and [cpan://strict] type links intact, to be processed by the monastic style. Only if it sees a string matching [.+](.+) (or, incidently, [.+][\d+] does it bother to process it.

      Again, what I proposed is an implementation that no one would notice if they just used the current monastic style of markup.

      After considering a couple of the comments here, I realize that some of the auto-formatting things would have to either be more intelligent or controlled through some sort of preference.

      As for intelligence, it would be easy enough to turn specific Markdown items off when it makes sense: two line breaks followed immediately by container-type HTML tags would *not* be parsed as a new Markdown paragraph. If it sees italics, emphasis, bold, strong tags, assume all asterisks are literal. Use literal asterisks if it sees something like "great idea*" without a matching /\*\w/ somewhere before it in the paragraph. Etc. Most of this would be trivial, the rest would be mostly easy (though I'm sure there would be a few difficulties).

      As for the option, I'd place a per-post checkbox for 'use Markdown syntax'; checking it would resolve conflicts between monastic markup and Markdown in favor of Markdown. When unchecked, all Markdown would be ignored. The default state of this checkbox would be controlled in user preferences.

      I also don't like excessive autoformatting of text. I do like making some interpolation available so that I can concentrate on my content, and not whether or not I've remembered to break my paragraphs or wrap quotations of other people in blockquote tags (Markdown lets you prepend the paragraph with a single '> ' to deal with it.

      I also feel bad for new posters that don't understand why all of their paragraph breaks (in the form of a double newline) disappear when they post, and they get chastised for it. Giving them an option that automatically deals with simple things like that is, I think, valuable.

      Does any of that make you more comfortable with the idea?

      <-radiant.matrix->
      A collection of thoughts and links from the minds of geeks
      The Code that can be seen is not the true Code
      "In any sufficiently large group of people, most are idiots" - Kaa's Law
Re: Markdown syntax useful to the Monestary?
by sauoq (Abbot) on Oct 28, 2005 at 19:25 UTC

    I approved and FP'd this node because I wanted to see some discussion about it. I don't necessarily support the use of Markdown, but I do think that some similar filter(s) would be a worthwhile addition. There are many out there and probably many of them have Perl implementations. I know about Text::Textile and Text::Tiki, for a couple examples.

    I agree with others in that I believe, if implemented, the use of such should be configurable via user settings and should be off by default.

    One reason why I think that Markdown might not be the right choice is that it wasn't created to solve the same right problems... From the Philosophy section of the Overview in the page describing Markdown's syntax:

    Readability, however, is emphasized above all else. A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.
    I don't think we really care much about how PM nodes look in plaintext.

    Some of the features I'd like would include:

    • Easier ordered and unordered lists.
    • Quick and easy footnotes.
    • Single character emphasis, strong, underline, super/subscript, and blockquote indicators.
    • Automatic paragraph tags. (If smart enough.)
    Super easy tables (like Textile's) would be really cool too.

    Of course, maybe custom implementations for some of this stuff would be better than trying to adapt an existing formatting language too. So, whichever. Or none at all if there isn't enough interest. It isn't like we don't get by just fine as is.

    Does anyone have any reasons why this kind of thing should not be implememented? I mean, assuming a clean integration with the current syntax could be accomplished? I can't really think of one outside of a "little gain for the effort" argument.

    -sauoq
    "My two cents aren't worth a dime.";
    

      I also think that some form of simplified markup would benefit PM, even if it only persisted until the node was commited.

      It's rarely a chore to edit existing html for correction of typos and similar, but hand generating lists and tables is a pain.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        Speaking of editing...

        Currently Janitors can look at how a node was originally typed-in, and make judgements as to how it was intended to be formatted, even if formatting is missing. They can also look at a node where formatting was used, but used improperly, and quickly ascertain what needs to be done to repair an unreadable node. Imagine if we had to learn all these different flavors of markup. I know you mentioned that the alternate markup form could persist only until the node is committed. But that presents its own problems for Janitors: Nodes that have passed through some sort of preprocessor probably won't retain the original characteristics of how they were typed-in. In other words, we may not be able to see where the author hit enter expecting a new line in his post, if the node has passed through a preprocessor. ...that's just one simple example.

        So if the node persists in its typed-in format, we'll have to learn multiple flavors of markup. If it doesn't persist in its typed-in format, we won't be retaining the node's original behind-the-scenes characteristics. Either scenario presents its own problems for Janitors.

        Now putting all that aside... If some sort of alternate markup were to be implemented here, rather than making it an explicit "user settings" checkbox, how about making it a tag at the beginning of the post, such as:

        <!-- use Markdown --> The rest of the post goes here, in its alternate layout. <!-- use HTML (the default) --> Everything after this point can be typed in HTML format.

        The advantage to this is that an individual node could be typed using several markup formats, switching between them using some sort of tag. In practice, people who prefer one format could simply include the necessary tags for that format in their node template, also contained in user settings.


        Dave

Re: Markdown syntax useful to the Monestary?
by 5mi11er (Deacon) on Oct 28, 2005 at 15:41 UTC
    Provided it does allow both the actual HTML markup as well as the "automatic" paragraph formatting if HTML *wasn't* otherwise being used, I would certainly vote for it.

    What I wouldn't want is for it to add extra paragraph marks when I'd already used <p> marks, but then I'd also used return to format my post so *I* could read it as I was typing. (ick, a bit convoluted, hopefully you understand what I'm getting at)

    -Scott

Re: Markdown syntax useful to the Monestary?
by talexb (Chancellor) on Oct 28, 2005 at 17:48 UTC

    I plodded around the link you provided and couldn't easily find any specification of what it does. I like the easy formatting style of using <p> and </p> tags to mark a paragraph. saskaqueer's comments suggest that some simple things would be more complicated using MarkDown; my preference is to keep it simple.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

        Thanks for the link. I admit I have little patience sometimes -- if it's not fairly obvious, I can't find it.

        I liked what I read until I got down to the part that said

          To produce a code block in Markdown, simply indent every line of the block by at least 4 spaces or 1 tab.
        Feh. I like the code tags -- I'm not crazy about having to provide leading white space to trigger a wiki type feature. I live with it in POD, but I'm quite happy with the tag approach that we currently have.

        Perhaps this feature could be an alternative -- as SlashDot or GrokLaw allow. How about that option?

        Alex / talexb / Toronto

        "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: Markdown syntax useful to the Monastery?
by demerphq (Chancellor) on Oct 29, 2005 at 12:58 UTC

    I've added you to pmdev. I dont know when/where you made this request, but normally the way it works is you ask one of the gods directly, in the CB if you can be added. They will either say no, or say yes or say that you should ask a different god as we have a policy of the god doing the adding is supposed to also do the supervision of the new addition. Which means that if the god you ask is to busy they will direct you elsewhere.

    Going to the direct point, unfortunately implementing something like this is probably going to be a lot more work than you might be thinking. PM doesn't normally do on-submit processing of nodes. We normally do on fetch processing of nodes. This doesn't mean its impossible, but it does mean that its going to be difficult.

    OTOH, I do think that something like this is worth consideration so don't feel like you shouldn't look into it. If you can come up with a clean implementation that isnt too controversial then im sure we will put it into use.

    ---
    $world=~s/war/peace/g