Re: Markdown syntax useful to the Monestary?

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.";

Comment on Re: Markdown syntax useful to the Monestary?

Replies are listed 'Best First'.
Re^2: Markdown syntax useful to the Monestary? by BrowserUk (Patriarch) on Oct 28, 2005 at 21:34 UTC
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.	[reply]
Re^3: Markdown syntax useful to the Monestary? by davido (Cardinal) on Oct 29, 2005 at 07:17 UTC
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.` [download] 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	[reply] [d/l]
Re^4: Markdown syntax useful to the Monestary? by BrowserUk (Patriarch) on Oct 29, 2005 at 07:46 UTC
It's probably a naive view by someone that hasn't witnessed the range of errors that you guys correct, but it seems to me that something like markdown ought to reduce your workload. If the conversion filter is any good, it will fail to allow commitment of a post that fails to produce acceptable html from it's markup and prompt the user to correct it before it will perform the conversion. The way I envisage it working is that once the filter accepts the markup, it sends the html back to the user and discards the markdown. The user then has to preview the html in raw and formatted states (as now) before submitting, giving them the chance to amend the html if desired. They could also hit the back button to return to the markdown version and tweak it further, before again attempting the conversion. In this way, the only markup stored is the html, the markdown would simply be an intermediate shortcut to arriving at acceptable html. And if that html is produced by a filter, it ought to be free of errors. If the user modifies the html, there is the possibility that they will screw it up, but that's no different to now, accept that they would be starting from an acceptable starting point without missing end tags or (PM) illegal tags. The same thing could be achieved by using an offline conversion I suppose, which would have the advantage of allowing a proper editor to be used instead of the editbox I'm currently typing in. The problem with that is either everyone has to produce their own filter/editor/submit/verify/re-edit script, with the consequent mish-mash of complience with site html standards. Or, someone produces a standard module for doing it and tries to make it general enough to work with the 1000 varieties of preferred editor. It's far from a big thing, just a convenience, if it is possible, and it doesn't impact the servers too much. 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.	[reply]


We don't bite newbies here... much
	PerlMonks