[wiki-standards] Hello - request comments on Creole

Mike Haseler mike at lenzie.org.uk
Tue Jun 3 15:26:44 CEST 2008


Dirk Riehle wrote:
> Hi, Mike,
> 
> Thanks for the note. We developed a precise grammar to cope exactly
> with these issues. We even developed two versions, one following the
> official spec, one taking astricter view. (I.e. require closing tags
> at paragraph end.
> 
Dirk,

I've had a bit of time to look at the EBNF grammar for Creole and it is 
very impressive. Not quite the meta language I learnt at University, but 
understandable for the most part.

Before saying anything, my own puny attempt is completely botched and I 
would frankly be ashamed if anyone were to see the code because it is 
far from good.

Firstly, I have to say, that I don't like the present creole 
specification at all, particularly this line-based grammar which assumes 
that e.g. a # on the end of a blank line is a list.

In effect this is saying that a list point token is one of an infinite 
variety of the form: "\n[ \t]*#"

For me a token must be clear and precise and consist of a unique set of 
characters, so it must be: "\n#" and so in this respect the creole 
specification fails to be clear and precise and follow my cardinal rule 
of "one way in, many ways out" aka "you need to have some knowledge to 
start formatting, but need only guess how not to have formatting".

Putting that into English, the user should know that *# etc. only have a 
unique meaning as the first character after the newline.

(After thought ... But of course, the typical user will try to enter a 
space at the beginning to prevent the star being turned into a bullet 
point, and wiki writers like to trim spaces meaning that in some wikis, 
the space will get automatically removed ... making the user very angry 
as their text gets turned back into a bullet after a save ... still what 
does the creole specification say about removing whitespaces, or for 
that matter breaking apart long lines ..... not much!!!)

Having made that decision, I realised that my first attempt was based on 
the concept of the "line" of text, and now that '\n' is simply part of 
the token, I really ought to be parsing the text as a single section 
with arbitrary tokens.

I notice the bold/italic presents some interesting problems. Given that 
I have added to the list subscript, superscript and underline, I guess 
there are some 32 different combinations of content in several different 
contexts, and therefore it really is going to be necessary to invent 
something to say: "

<content>:=
	<**>[<content> ~<**>]<**>
	| <//>[<content> ~<//>]<//>
	| <^^>[<content> ~<^^>]<^^]
	|etc.

Mike





> You can find things on riehle.org incl tools to get you implemented
> quickly. Follow the wiki tag.
> 
>>From the traffic and requests I get through this I can reassure it is
> anything but dead ;-) At this stage all people want is just one
> solution, no hassles.
> 
> (And sorry, I'm not monitoring the Creole wiki.)
> 
> Cheers,
> Dirk
> 
> 
> 
> On 6/2/08, Mike Haseler <mike at lenzie.org.uk> wrote:
>> Hi,
>>
>> I've spent the last few weeks trying to come to grips with what is
>> optimistically called the creole "specification".
>>
>> I say "optimistically", because because even the very simplest things
>> like whether there can be a space between bold and the text isn't
>> defined. (ie **bold** vs. ** bold ** )
>>
>> I believe the problem stems from a total opposition of goals between the
>> project and my own requirements.
>>
>> Creole seems to be a "nice-to-have" list of "similarities" which you
>> "might like to implement" if you feel like it.
>>
>> In contrast, I just want a defined markup specification so that I can be
>> sure I am compatible without all the hassle of trying to work out what
>> this or that should do.
>>
>> I've reached the stage, where I'm basically dumping the creole idea as a
>> waste of time because I keep posting comments on the wiki and get no reply.
>>
>> ======
>> Aim,
>>
>> my aim is to create a basic form of format that can be used across a
>> wide range of applications from wikis, to blogs, to message boards, to
>> private messages, to adverts for houses, to address lists for scouts.
>>
>> The applications have two things in commons:
>>
>> 1. They share the same username/password/authentication system
>> 2. They share the same text interface.
>>
>> I'm not in principle against wizi-wig textual interfaces, except that I
>> regularly post on bulletin boards with such wizi-wig interfaces, and I
>> never use them, so they are a toupee to markup not hair transplant.
>>
>> =====
>> Reason for writing,
>>
>> I reached that stage in the pistophonous curve where I wished I'd never
>> started this project because I can't write one bit of code without
>> finding that I've got a bug in another bit, and to be honest the creole
>> spec is light relief compared to debugging some of the stuff I've written.
>>
>> And, I'm now so deep in the shit, and have so much newly written code
>> that I realise it's going to take months and months to test this blasted
>> thing .... and I may as well get into practice with blogging because
>> with no one else involved in the project, I'm going to be talking to
>> myself for months if not years at the current rate of progress.
>>
>> Mike
>>
>> PS. 14,000 characters on my test case, and I'm still regularly finding
>> new problems and adding them to my test cases. (can a table have a
>> numbered list, why doesn't Firefox implement &shy;)
>>
>> _______________________________________________
>>
>> wiki-standards mailing list. wiki-standards at wikisym.org
>> http://www.wikisym.org/cgi-bin/mailman/listinfo/wiki-standards
>>
>> For the wiki-research, wiki-standards, wikisym-announce mailing lists,
>> please see:
>> http://www.wikisym.org/cgi-bin/mailman/listinfo
>>
> 



More information about the wiki-standards mailing list