Welcome!
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
Thanks!
-- 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...
--Yves, 2007-01-30
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
Restricted rights#
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 ## and {{{}}}, 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
Add new attachment
List of attachments
Kind | Attachment Name | Size | Version | Date Modified | Author | Change note |
---|---|---|---|---|---|---|
zip |
nme-ruby.zip | 1.6 kB | 2 | 10-May-2008 01:38 | MattMcKeon | Patch to add a Ruby wrapper extension to the 071015 distribution of NME |