Although Creole is mainly designed as a language to bring wikis closer together, I'm sure that many solutions are universal enough to be used in other text applications. We hope that both Sysquake and Creole will benefit from your presence here.
-- RadomirDopieralski, 2007-01-23
-- Yves, 2007-01-25
I'm wondering why you mention definition lists. Are you using them a lot? It seems to be one of the least popular html elements, many people don't even realize it's there. It also doesn't have a counterpart in many text markup languages -- you usually just use normal lists or paragraphs combined with emphasis, or even a table. Even Google recognizes that.
Not that I'm totally opposed to it, but it's the first time anybody mentions he misses it, so I'm curious :).
Yes, I find them useful. At least MediaWiki supports them, with semicolon/colon syntax. We (Calerga) shall eventually use a simple markup language for help files in Sysquake; the current documentation, whose original version is in HTML, does contain definition lists (see e.g. the list of types; there are several other lists on that page). Since a clean and simple syntax already exists in the most common wiki markup, I think Creole should support it; it would be simple to implement.
I'll probably add them anyway to my Creole prototype to be more convincing...
I noticed on WikiMatrix that most wikis use the semicolon/colon syntax, but I just don't think it's that common among wiki engines. That sounds more like something for WikiCreole 1.0. I'd be curious to know what other developers think, but it seems like something that would be ExtensibleByOmission
-- ChuckSmith, 2007-Jan-30
Not allowed to revert spam anymore, at least on ExternalDiscussion :-(
-- Yves, 2007-Feb-15
I am getting mad with this ACL Bug. The dilemma for me right now is: If i enable page chache pages get locked by accident. If i disable it ACL on pages do no longer work making certain pages targets to robots. Arg.
-- ChristophSauer, 2007-Feb-15
Can you elaborate on the "paragraphs a la Mediawiki"?
Once again I'm apologizing on this wiki. I must emphasise that all the taling I do here is only my own personal opinion, and not the one and only "right way". I may (and often do) sound forceful or even patronizing -- that's because of all the emotions I put into this. I'm aware that it's not good or pleasant for others, hence those apologies.
My reaction with the "imagined problems" was definitely over the top -- we must rely on our imagination when hunting for potential problems, the testing is good for evaluating the scale oft he problem and effectiveness of solutions, but it's our imagination that helps us track them.
The interpretations of the goals is definitely disputable -- actually that's what I intended to discuss by starting with a view so opposed to yours. I'm sorry for being to offensive.
-- Radomir Dopieralski, 2007-Mar-15
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 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
-- YvesPiguet, 2007-Apr-23
Thanks for your comment on 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 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 email to discuss how to release it? Thanks!
-- YvesPiguet, 2008-05-12
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.
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