-
-
Notifications
You must be signed in to change notification settings - Fork 371
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Top level API design #4
Comments
Options (from marked, remarked, stdm):
Options, marked by |
Option:
|
Geek parts. Needed only for deep control, like tokens post-processing, before rendering. That's very preliminary, and i don't like it. Just to remember, that we should provide easy methods to parse inlines only and so on. var Remarkable = require('remarkable');
var md = new Remarkable({.. options ..});
// tweaks (usually not needed)
md.lexerBlock.at('nptable', null);
md.lexerInline.before('link', myFN);
//
// Simple run (most cases)
//
console.log(md.process(string));
//
// Advanced run
//
var state = md.start(string);
// when we need inlines only, not wrapped with p
md.lexerInline.tokenize(state, 0, state.lineMax);
md.renderer.render(state);
console.log(state.result); |
@jonschlinkert , see updated options list in first message. Only one for It's still possible to disable separate markup (tables, ...) via api, but i'm not sure we have to expose it to options. At least, until many people ask it. Also advice better name for language prefix if possible. Now it's not clear that it's for fences. But i can't invent something short and without camelcase. |
I think a lot of users will be familiar with The only feature that I would like to see on the list is |
I expected, that tables support will be on by default. And if someone wish to disable tables, he will do something like Is something wrong with this approach? Are there situations, when tables have to be disabled? |
You are probably right, it will take some time for me to get as familiar with the spec as I need to be. Everything you're saying makes sense. and sorry, I meant to reply to this. I don't like the new github notifications, I never notice them anymore. |
...and is it just me, or is anyone else find it interesting that the spec is being partially championed by Jeff Atwood? I know he has been "talking about markdown" for a long time, but I can't help but think about stack overflow when he mentions markdown. SO has the absolute worst implementation of markdown that I've ever used. It's painful to write on that site. I really hope the spec doesn't reflect SO's idea of markdown. |
be specific, what exactly you don't like. |
At first I was gung-ho about it all as it seemed to have a lot of momentum behind it. The more I watch it the more I worry it is becoming a programmers tool. Perhaps not intentionally, but nevertheless going that way. I think Markdown is an idea that anyone can adopt. Once people use it and grok the simplicity of its control they will start to want it more. So many creative opportunities could come from Markdown if it was a ubiquitous writing tool. For one the HTML of the web would start filling with real semantic content. I think the only fix is for John Gruber to get something going on GitHub and really spell out how he sees Markdown in the future. I suspect he never wanted to clearly define it so that it could evolve more freely. |
@puzrin I like everything you're doing in this project. I meant stackoverflow. For example, they don't use gfm, they require code to be indented for code blocks. Does anyone still do that? gfm allows you to identify the language, get syntax highlighting, creates semantic, contextual relevance for the content so it is more likely to show up in searches etc. IMO gfm does it right. |
@howardroark, I'm not sure what where you're coming from. this is a programmer's project to build a parser/compiler for markdown. I'm excited as hell about what @puzrin / @rlidwka / @Kirill89 and team are doing right now. We're going to make this project amazing! What impresses me about how @puzrin is managing the development is:
Regarding philosophical issues with the language, how it will be adopted by the community, what users want to actually do versus what we release, these are all things that will necessarily need to be learned as we go. It's never good for the momentum of a project to kill progress by over-analyzing questions that are too hard to answer at present - e.g. paralysis from analysis. This is especially the case when there are plenty of cut and dried things that can be done without debate. Remember that code can change, options can be implemented, and the API makes remarkable extensible. At the end of the day, regardless of the features we implement, the community and users will decide how markdown should be used. |
I 100% agree. The only element of whitespace that should be relevant is new
|
@jonschlinkert I needed that! Sorry, I was mostly just rambling about the I'm super excited for this project. @Purzin is doing an awesome job, and I'm so using this once it's ready. Consider this my last troll-by until I 100% agree. The only element of whitespace that should be relevant is new
|
@howardroark, no worries, you care a lot about what's happening in this space and you're lending your voice to ensure things head in directions that's good for all. we'll need champions, so I'd love to see you stick around help make get the word out when the time is right! |
After thinking a bit,
|
Reference http://talk.commonmark.org/t/why-not-allow-images-without-alt/617 I tend to add option { easyalt: false } to allow skip empty [alt] for images. If nobody like it - that will be my personal undeletable madness :) . It will be off by default, and will not harm anyone. Or, may be it can be published as separate package, that's also acceptable for me. Not decided yet. |
I just found remarkable today and it looks very interesting. It seems to be targeted towards a commenting vs page/content creation which is what I am looking for. Regarding the API, the html and xhtml flags are a bit confusing. Is |
See https://github.com/jonschlinkert/remarkable#usage and demo. |
Suggestion: no global singletons - that's a great way to fuckup everything.
new
? (i think not)remarkable
exemplar.Options:
The text was updated successfully, but these errors were encountered: