| At line 52 added 139 lines |
|
| No problem, I may have overreacted. I find difficult to argue with a single person, in public, when |
| I can't know whether I'm in a very small minority (I suspect I'm not totally alone) or not. I'm not |
| sure a wiki is the best way to obtain the best solution. The problem with consensus rather than vote is |
| that you're never sure if the consensus is shared by a small minority which cared to express an opinion or |
| if it's more prevalent. For instance, I've written several times I'd like to separate double-sharp and triple-brace, you did |
| too, and you've written a proposal; should I say "me too" or assume it's known, with the risk that the proposal |
| isn't backed by enough people? Another example, the escape character: one guy doesn't like tildes |
| but may eventually accept them, one wants to keep double backslash for linebreaks, one wants an |
| escape character but is againt backslash as an escape character if double backslash remains the |
| breakline markup, and finally one is doubtful with the concept of escape character. Who will win? |
| Will it be for good reasons? |
|
| Concerning what I've listed as my requirements and my concerns, they reflect needs for closed-source |
| software which will have several revisions in the next few years and will have to be backward compatible. |
| I understand that's a very different application from what most (all?) other contributors here are interested |
| in, i.e. wiki engines. At the same time, I don't fully understand why Creole should be so permissive. |
| A stricter standard would have many advantages also for wikis; "multi-platform, multi-system, fool-proof, |
| implementation-independent" is maybe a goal difficult to reach, but going in this direction isn't that bad. |
| I deduce from some contributions that this opinion is shared by a few people here. |
|
| So ideally, I'd like that more people be involved in more discussions, especially when two guys have |
| opposite opinions and are blocked with increasingly strong arguments. |
|
| Wrt "paragraphs a la Mediawiki", I guess you refer to "Indented paragraphs à la Mediawiki" in my wishlist. |
| I mean paragraphs which begin with a colon, used in virtually all discussions in Wikipedia. Actually Mediawiki |
| doesn't support line breaks in indented paragraphs, but I think they should follow the [[Multiline list items]] |
| proposal. |
|
| -- Yves, 2007-Mar-15 |
|
| Please do put your feedback on the pages, even if it's just a "me too". Silence usually means that you didn't read it yet or don't care. We certainly can use other media than wiki for working on Creole; for instance, I plan to propose a [[Wikipedia:Gobby|gobby]] session for improving the organisation and wording of the whole spec at some time, so that it's easier to understand and follow. |
|
| As for *-proofing of Creole: certainly it's nice to have it. I imagine we will favor more robust and foolproof solutions anyways, simply because they usually are the best from the engineering point of view. I agree that heuristics tend to be ugly, for example (in the context of CodeStink). But note that general statements don't hel here much -- proposing concrete solutions works much better. |
|
| As for discussing and arguments, well, maybe it's idealistic approach, but I'm a great fan of an old movie "Twelve Angry Men" :) |
|
| -- [[Radomir Dopieralski]], 2007-Mar-16 |
|
| So am I. But from a control point of view (my main research area), feedback effectiveness is |
| limited by sensor quality and delays have a destabilizing effect. We're sometimes close |
| to the limit where good openloop (no feedback, or heaviliy filtered) might be better than |
| trying to increase the feedback gain. With twelve (wo)men around a table, the situation would |
| be easier to handle. |
|
| -- Yves, 2007-Mar-16 |
|
| Can you think of any improvements in the technology or process that would be helpful? |
| Anybody else? |
|
| -- [[Radomir Dopieralski]], 2007-Mar-16 |
|
| ---------------------------- |
| I know that you where quite irritated by my comment on the first poll, sorry again, Yves. Your opinion is still missing on the [[Creole 0.6 Poll]]. Only with your opinion I feel it is really complete for now. Therefore, could you add your opinion, please? |
|
| -- [[ChristophSauer]], 2007-04-22 |
|
| Done. |
|
| -- [[YvesPiguet]], 2007-Apr-23 |
|
| Thanks for your comment on [[Talk.YaroslavStavnichiy|my page]]. I did not notice NME when first reading the site. Now I looked at it and I think it is great work. Perhaps you should mention on the [[Engines]] page that it is written in C. It is hard to find something other than PHP these days, so mentioning C should draw attention of interested people. |
|
| I run your test page through my parser and found some differences. I think the way NME renders the following fragment is not correct: |
| {{{ |
| * first item of an unordered list |
| # sharp invalid for unordered list, hence it is a plain character |
| ** first item of sublist |
| *# only the star matches the top-level list |
| ## monospace |
| }}} |
|
| Sharp in the second line should be treated as a beginning of a new numbered list. Consider different example: |
| {{{ |
| This is regular paragraph. |
| # sharp means nothing within paragraph, hence it is a plain character |
| }}} |
|
| NME would render it differently, and I think, correctly -- it will start a new list. |
|
| Creole does not require blank line before starting a new list, so it should not matter what was before it. And if one requires # in the beginning of the line he should escape it, no matter where it is: in a paragraph or within a list item. |
|
| I do not agree with the fourth line as well. Star matches top level of the list - that's right. Why doesn't # open a new numbered sublist? Consider the following example: |
| {{{ |
| * first item of an unordered list |
| *# only the star matches the top-level list |
| }}} |
|
| NME does render it differently, and I think, correctly. |
|
| By the way, while examining your test fragment I found a couple of bugs in my parser too :) Not fixed them yet. |
|
| -- YaroslavStavnichiy, 2007-12-17 |
|
| Thanks for your comments! |
|
| The problem with switching list kind without blank line is that there will always be ambiguities: |
| {{{ |
| *item a |
| *#item a.1 |
| **bold or item a.a? |
| }}} |
|
| I'd like an official clarification, whatever it is (provided it's sensible!), but I'm not sure it's worth changing NME now before a consensus is reached. |
|
| -- [[YvesPiguet]], 2007-12-18 |
|
|
| Hi Yves! Thanks for making NME, I'm finding it very useful. FYI I've written a Ruby wrapper extension for NME, so that it can be easily used from Ruby scripts. I've [[http://www.wikicreole.org/attach/Talk.YvesPiguet/nme-ruby.zip|attached it here]] as a patch for the NME-071015 distribution. To use (if you have ruby installed on your system): |
|
| {{{ |
| unzip NME-071015.zip |
| unzip nme-ruby.zip |
| cd NME-071015 |
| patch -p1 < ../nme-ruby.diff |
| make nmeruby |
| }}} |
|
| It should build the extension for whatever your platform is. |
|
| -- [[MattMcKeon]], 2008-05-09 |
|
| Great work, Matt! If you're interested, can you contact me by [[http://nyctergatis.com/contact.html|email]] to discuss how to release it? Thanks! |
|
| -- [[YvesPiguet]], 2008-05-12 |
|
| Hi Yves, |
|
| I would like to Hack Nyctergatis Markup Engine to reduce some markups like "~[[" to "~[", "~<<" to "<", etc. |
| What's the best way to do it? I could hack it but don't know what's the best way. |
|
| Thanks, |
| srw |
|
| Please only append to this discussion page so that one can easily follows questions and ansers. |
|
| Edit NME.c and modify function parseNextToken to not require double characters. |
|
| -- [[YvesPiguet]], 2008-08-24 |
.