archive-org.com » ORG » W » WIKICREOLE.ORG

Total: 1035

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Talk.Engines Using Asterisks For Lists And Bold
    Symposium and the Nuveon GmbH view find Quick search type ahead Recent Searches Clear Talk Engines Using Asterisks For Lists And Bold Your trail Talk Creoleparser py Home Talk CrossmarkCreoleUnification Home Talk CustomizationAlternative Home Talk EBNFGrammarForCreole1 0 Home Talk EndOfTableAmbiguity Home View Page Discussion V iew A ttach I nfo Confluence requires a space after the asterix for lists bold otherwise Bold Item 1 Subitem 1 1 Bold SubItem 1 1 1 Bold Item 2 p b Bold b p ul li Item 1 ul li Subitem 1 1 li li b Bold SubItem 1 1 1 b li ul li li b Bold Item 2 b li ul JaredWilliams 2007 02 06 ErfurtWiki whitespace is optional after the asterix Asterixes at the beginning of the line are assumed as lists even if there is more than one Cannot start a line with bold Bold Bold Item 1 Subitem 1 1 Bold SubItem 1 1 1 Bold Item 2 ul type circle li Bold li ul ul type circle li ul type circle li Bold li ul li ul ul type circle li Item 1 ul type circle li Subitem 1 1 li li b Bold span class NotFound a

    Original URL path: http://wikicreole.org/wiki/Talk.EnginesUsingAsterisksForListsAndBold (2016-02-11)
    Open archived version from archive


  • Talk.Eric Chartre
    Symposium and the Nuveon GmbH view find Quick search type ahead Recent Searches Clear Talk Eric Chartre Your trail Talk CrossmarkCreoleUnification Home Talk CustomizationAlternative Home Talk EBNFGrammarForCreole1 0 Home Talk EndOfTableAmbiguity Home Talk EnginesUsingAsterisksForListsAndBold Home View Page Discussion V iew A ttach I nfo Welcome Thanks for your great ideas I ve added some of them to my wishlist I agree that leaving out the presentation and implementation details is

    Original URL path: http://wikicreole.org/wiki/Talk.EricChartre (2016-02-11)
    Open archived version from archive

  • Talk.Escape Character Decision
    typo however I d prefer not specifying an escape character at all AlexSchroeder If you implement your parser according to the EscapeCharacterProposal it only escapes in certain combinations this does not escape anything this escapes heading syntax see EscapeCharacterProposal Scope of Escape Character Christoph Sauer 2007 April 04 Hm then we need to rewrite that proposal because now it reads This way stars slashes and other markup characters when found in the original text can be easily escaped to be rendered as themselves The special escape character when put before alpha numeric characters could be rendered as itself no escape As far as I can tell the slash is used for italics and therefore belongs into the other markup characters category At the same time the slash is clearly not in the alpha numeric exception AlexSchroeder But then all users of Sysquake Matlab Octave etc whose I am should complain because has a meaning in these programming languages It s easy to put paths and expressions which are always more likely to have unexpected Creole markup than plain text between triple braces An escape character should be reliable and not based on ad hoc heuristics or a moving target The only alternatives I see is to use another escape character such as the percent character or X to escape character X Both have problems percent is more common in text and likely to occur before punctuation and double tilde is verbose and makes escaping tildes cumbersome YvesPiguet 2007 Apr 4 Agreeing with Yves about reliability of escape character Is the Unix home directory really such an important point that cannot possibly be escaped where occurring like the need to escape so many other way more frequent in my use cases character combinations I propose defining tilde as escaping the next character whatever that may be including CamelCase or lowerCamelCase to avoid linking in Wikis supporting such links The tilde in the homedirectory has to be written as double tilde bin Simple understandable and I believe memorizable for content authors Gregor Hagedorn 2007 Apr 4 I have collected some input looked at some markups that use escape characters Markdown and re structuredtext written down the common problems with escape characters and here is what I came up with Scope Escape character should have very simple scope rules Escaping should only affect a single character appearing immediately after the escape character Thus escape character is unsuitable for escaping WikiWords and a separate rule must be introduced for it if the wiki adds WikiWords to Creole This rule may reuse the escape character but would be probably better to use the standard exclamation mark Escape character should not work inside preformatted blocks because that would require escaping all the escape characters in any pasted code There is already Add No Wiki Escape Proposal that works fine inside preformatted blocks Whether it should work inside nowiki spans or not is disputable On one hand the same argument as for preformatted blocks works here On

    Original URL path: http://wikicreole.org/wiki/Talk.EscapeCharacterDecision (2016-02-11)
    Open archived version from archive

  • Talk.Escape Character Proposal
    the escape character I like the option being able to use creole in a scripting language as simplified HTML Therefore I don t like percentage for the reasons you stated above IMO we should decide between using space as an escape character space in combination with special cases of markup usage or using tilde which is more visible but could be confused with tildes standing in the text for themselves Chistoph Sauer 2007 Mar 05 Just to clarify Changing linebreak markup two backslashes is not necessary even if backslash is the escape character I m not asking for it to change Tilde is not collision free That s the main problem Other issues exists though Michele Tomaiuolo 2007 03 05 But I d do ask if backslash becomes an escape character Having multiple escape characters or multiple conventions repeated characters to produce a single one like with spaces before triple braces in preformatted blocks would cause unnecessary confusion I m not against or though YvesPiguet 2007 03 05 Christoph so what would be the scope of tilde in your proposition both in terms of where it acts as an escape and what it escapes Radomir Dopieralski 2007 Mar 05 I added it to the proposal Christoph Sauer 2007 Mar 06 Can t we simplify a lot the context where the tilde is recognized as an escape character by choosing only non alphanumeric characters It s likely I think it s even a goal of Creole that different implementations will have a different set of markup sequences if the rule is tilde is an escape character when it s followed by Creole markup here is the list but it will change in the future it will cause a lot of confusion and incompatibilities when switching to new Creole versions Alphabetic characters are a useful exception for two reasons 1 tilde letter is frequent in urls 2 we don t want alphabetic characters in Creole If the rules are different in inline nowiki there will also be confusion I suggest we keep the current rules for nowiki which do permit to have three right braces in the unfrequent cases where we need them So I suggest that where Creole markup is interpreted i e everywhere except in preformatted blocks inline nowiki and possibly modules with and latex with when if they re accepted tilde single nonalphanumeric nonblank char verbatim nonalphanumeric char everywhere else tilde normal character YvesPiguet 2007 Mar 06 Restricting tilde or any escape to non alphanumeric is a good idea but it would work only in creole only wikis The most frequent use of escape character in my experience is in Wikis that support CamelCase for linking such as the JSPWiki here is set up JSPWiki has an option for this Unfortunately when talking about programming or xml schemata but also current research programmes names CamelCase words that are not links are rather frequent I believe the Creole escape character should work for Wiki native markup needs as well as for pure Creole GregorHagedorn 2007 Mar 06 For complete words I d use inline nowiki once it isn t rendered in monospace font like braces in BibTeX to preserve case here BibTeX is written as BibTeX but I d rather have it in non monospace font YvesPiguet 2007 Mar 06 Now we only need to put that table on the cheat sheet Indeed I was blind escape character really greatly simplifies the markup Radomir Dopieralski 2007 Mar 06 I ve added it to Nyctergatis and its doc for those who want to try YvesPiguet 2007 Mar 06 I m experimenting with the proposal but I ve not understood if only a single char has to be escaped or a whole sequence For example should a tilde before a sequence of asterisks escape only one two or the whole sequence It makes a great difference as in some syntaxes even a single asterisk can be meaningful As I implemented it now the escape is applied to the first character following tilde plus all of its repetitions For example in all asterisks are escaped but not slashes It s an experiment clarifications are welcome Alternatives escape just the first asterisk escape all non alphanumeric chars all asterisks and slashes in the example I d still prefer a single char to be escaped But this should be made clear and users should be advised to escape each character not meant to be markup to avoid side effects Otherwise there s nowiki IMHO the proposal is good but it should be made a bit more general with an eye to extended syntaxes mixed mode Also an intuitive consistent way to escape closing braces in inline nowiki sections is still missing Thanks in advance Michele Tomaiuolo 2007 03 06 I think the simplest solution for implementation but more importantly also for description to the user is to escape a single character For instance abc would escape the first star leaving abc which has no Creole markup so the result is abc Alternative notation would be abc or abc The problem with escaping an unlimited number of identical characters is that there are cases where you want to recognize markup e g the following path in italic home user Escaping whole Creole markup sequences isn t the way to go imo because the set of markup sequence depends on the engine and on Creole version and when you want to escape something it s usually to control exactly which characters to produce in the output not to have whole Creole sequences In Nyctergatis if you choose Creole output all etc are escaped even when unnecessary There are still some characters from more exotic markup which should be escaped but aren t but this hints that this escaping rule is very simple to apply In inline nowiki there is already the following sequence for the single right brace it seems to be impossible to write it with the current engine used by wikicreole so I ve replaced

    Original URL path: http://wikicreole.org/wiki/Talk.EscapeCharacterProposal (2016-02-11)
    Open archived version from archive

  • Talk.Escaping Curly Braces In Nowiki
    closing braces where they might be considered as nowiki or preformatted end tag there is one additional rule that works for both inline and block three closing curly brackets preceded by a tilde are escaped although otherwise tildes do not escape in nowiki does not allow for the sequence tilde three closing braces at the beginning of a line Making tests in the JSPWiki sandbox the tilde works like spaces in the current Creole one tilde is removed when followed by three closing braces but it s removed anywhere in block or inline nowiki So it s a completely different kind of escape character than what we have at other places BTW JSPWiki and Creole would be incompatible anyway in the way leading spaces are used More tests in JSPWiki sandbox I ll use and instead of braces here to make sure the output is what I want in inline nowiki the tilde escapes three braces not one foo bar foo bar and foo bar foo bar how to have one trailing brace I don t know foo foo with last brace outside nowiki i e no greediness as in the current Creole but foo etc foo etc with unterminated nowiki So trying to solve the very uncommon case where we have three closing braces in the middle of nowiki we break if we follow JSPWiki the very common case where we have one trailing brace YvesPiguet 2007 Jun 21 What JSPWiki does is that a tilde disables the next directive not the next character If the next characters do not form a directive the tilde is left as is Therefore one trailing brace you get simply by adding a single brace separated with a whitespace e g foo Now since the JSPWiki parser is not based on a proper

    Original URL path: http://wikicreole.org/wiki/Talk.EscapingCurlyBracesInNowiki (2016-02-11)
    Open archived version from archive

  • Talk.Extensible By Omission
    is worth the occasional error Radomir Dopieralski 2007 Mar 14 The problem is more serious when one adds new features For instance if double comma is not included in Creole 1 0 and 40 million people begin using it for inline quotes and double comma is added to Creole 2 0 it will be painful to upgrade Markup languages like XML or HTML are much safer because character sequences reserved for markup are well defined elements attributes and entities that s about it and a given version can list them exhaustively What we could do with Creole is to list all sequences which are optional such as double underscore for underlined text single lessthan for HTML etc or reserved double dollar double exclamation mark or even plus or dollar at the beginning of a line so everyone knows what to escape to be safe This goes against ExtensibleByOmission but I agree with Gregor on its limits YvesPiguet 2007 Mar 14 That s what I attempted in HintsOnExtending and what can be done more systematically in CreoleAdditions Still I see no problem with leaving out of the specification things like markup inside headings or links Radomir Dopieralski 2007 Mar 14 Yes that s exactly what I meant The problem with not being explicit enough is that the author shouldn t assume her markup is guaranteed to stay verbatim in headings for instance In a description of hotels you should write something like Hotel du Lac or Hotel du Lac to be safe wrt future Creole versions or engine upgrades YvesPiguet 2007 Mar 14 I ve written it in Talk ExtensibleByOmission but I ll rephrase it here It s a wiki not a multi platform multi system fool proof implementation independent code framework If the wiki admin changes something upgrades version installs new plugins imports page database etc it s is natural to check the results and possibly run some simple search and replaces in case of conflicts Even if the fault is not detected immediately it s easily fixed by the first user who sees it Dead wikis with no users correcting the page text are safe too they obviously don t receive parser upgrades or new modules I can see three most common scenarios A wiki that uses native markup adopts Creole either in mixed mode or as the new markup All the pages need to be checked and maybe even converted anyways A new wiki is created and uses Creole and some of CreoleAdditions After some growth the community decides to add some new markup that is needed the admin writes appropriate plugin or module and picks the markup that is the least likely to conflict with existing page database If there is high possibility of conflicts then the pages are checked Some text is moved between two wikis supporting Creole The user who pastes the text checks proper rendering Radomir Dopieralski 2007 Mar 14 Experience shows I d better not argue at this stage so I won t

    Original URL path: http://wikicreole.org/wiki/Talk.ExtensibleByOmission (2016-02-11)
    Open archived version from archive

  • Talk.Extensible Formatting Element Proposal
    Again as at least TWiki and MediaWiki show using extensible markup is NotNew The proposal is about the structure or creole not about using specific characters to achieve the extensibility The Creole grammar structure that is proposed is an alternative to Yves proposal to add yet another n I count 11 already double punctuation signs Gregor Hagedorn 2007 Apr 04 Gregor I agree with you that we need either this or one of the other things you proposed Currently I m in favor of the GenericExtensionElementProposal but that may be just because it was discussed best so far Now to address your needs I see several problems and several possible solutions these are to start the discussion not to counter your arguments mind you Also note that there is already Superscript And Subscript Proposal and that it will likely be included in Creole Additions The problem with advanced formatting in links and page names URLs don t support it They do support the Unicode alternatives I mentioned in the Talk SuperscriptAndSubscriptProposal at least when the engine uses UTF 8 So Creole would have to specify an algorithm for encoding this formatting into URLs which is out of the Creole scope and poses an additional problem as not all wiki engines allow the same set of characters in their page names due to either design decisions or implementation of their storage think C2 Note how the original wiki swiftly sidesteps this problem by spelling out any advanced markup in page names CeePlusPlus Another problem with advanced formatting it s going to be by necessity quite elaborate I doubt your users will me happy writing 2m sup 2 sup and I m pretty much sure they won t be happy reading it Using Unicode with some nice way of enabling the users to enter it comfortably in the engine like buttons or even just a list of them for copy pasting is the most readable and portable way Using a LaTeX like plugin not necessarily LaTeX it may render to normal HTML and use even simplier syntax custom crafted for the purpose is a second in order comfortable option at least in my opinion and limited experience Compare C₂H₅OH C 2H 5OH C sub 2 sub H 5 OH Lastly things like text alignment floating of elements spacing colors etc are the domain of web designers and are best accomplished using styles and style sheets Sure a way of inserting a classed div or span would be then handy but that s hardly core wiki syntax Radomir Dopieralski 2007 Apr 05 Re The problem with advanced formatting in links and page names URLs don t support it My apologies I mean in the link display text not in technical page name What my community needs need is Synonyms Abies alba var alba L Abies alba subsp alba L In biology the Genus names and epithets MUST be italics but not the rank or the author name There is a single page for this subspecies and using the name to link to it is natural But the display of the link inside a paragraph must be formatted I agree about my proposal being poorly readable but I find the original super subscript with specific Creole just as bad Unfortunately Unicode has only very few super subscript characters I believe it is not a solution to super subscripting I still counted 11 more formatting proposals Perhaps we should forget the proposal to use html like syntax perhaps indeed what we need is CSS support My major point was that currently Wiki engines support a lot more than is in Creole and I hate having to use a mixed mode with 11 more reserved characters for the native wiki extensions Open up a structured way in Creole to let Wiki developers extend their formatting and I am happy And perhaps start using the same methods for the medium important formatting issues in my mind that includes monospace formatting so I think this proposal is timely Gregor Hagedorn 2007 Apr 11 How about using a special plugin custom written for the specific use case giving you a way to achieve desired markup easily chem c2h5oh the plugin would know how to format the text simply from the context and would output span class chem C sub 2 sub H sub 5 sub OH span or maybe even with colors to highlight important details Note how the raw source is still readable The text is also easily readable on wikis that don t have this plugin installed just not as nice I think this is the way to go when a wiki community has some special needs making the wiki markup universal also makes it complicated and unreadable It is so simple just because it is small Then again there is nothing wrong with extending Creole it was meant to be just a small common subset of most important things to ease transition between wikis not a complete wiki markup with all bells and whistles that any wiki engine can have Radomir Dopieralski 2007 Apr 11 I don t mind having such a custom plugin but it is not very general and does not solve most problems I believe there should be a general solution The real problems to me are the variable names that include subscripts superscripts including letters I don t mind if the solution is a bit more complicated than normal markup There is a huge difference between not possible using very simple markup and not possible at all Not possible at all means I get the mail from content authors how to do it and if I cannot offer them a solution they walk away I don t believe they will walk away if I can tell them well it is a bit complicated but here you go The JSPWiki CSS extensibility is a great thing in this respect and it would be enough to cover super subscript monospace etc Gregor Hagedorn 2007

    Original URL path: http://wikicreole.org/wiki/Talk.ExtensibleFormattingElementProposal (2016-02-11)
    Open archived version from archive

  • Talk.Generic Extension Element Proposal
    t like But it isn t always possible And pipes for instance are frequent in LaTeX BTW when do we accept multiline list items I m used to multiline paragraphs because it s easier to read and it s supported by Creole but if you look at the source code of this very contribution you ll see that my three list items look weird because I had to remove line breaks to let wikicreole scan them correctly YvesPiguet 2007 02 27 I don t think name clashes are an issue since they re internal to the wiki anyway it might even make sense to use something like plugin 1 If you want to have a global namespace for these you will also probably need to add things like version information as well and then it gets messy The whole point of the plugin syntax is that it allows a wiki engine to use native extensions without losing them in the edit I don t think the point of actually moving content from one wiki to another has ever really been their objective Janne Jalkanen I fail to see how using a domain name prevents name clashes when moving between different wikis After all it s pretty common that someone makes a neat plugin and then makes several versions for different wiki engines I think that the content of should always be considered engine specific and either escaped or converted when moving between wikis You are right about the pipe What other solution there is maybe Or maybe if we chnaged th order of the alt text and plugin this is some plugin pluginname some paramaters with pipes RadomirDopieralski 2007 02 27 Wiki A has latex mapped to unaffiliated radomir dopieralski macro latex So latex src a 1 does its thing Wiki B has latex mapped to unaffiliated jared williams macro latex and uses latex a 15 Both can import the others pages as long as they know how each other maps the markup to actual plugin implementations There is also the question of how much markup to allow in the alt text allowing all the markup would allow better approximation of the plugins output Could also allow plugin nesting so if the outermost fails it attempt a fallback to the next innermost I think there are few situations when the alt text would be displayed When the plugin is missing the plugin fails due to some exceptional circumstance ran out of file space for instance If the plugin is missing or fails and is going to degrade the quality of outputted page then there should be some distinction maybe a red bar to the left with link to a footnote explaining more In PHP there is an error warning message supression operator So whilst Plugin insertion failed Could not find plugin latex Plugin insertion failed Could not find plugin latex would generate a warning around the alt text Plugin insertion failed Could not find plugin latex Plugin insertion failed Could

    Original URL path: http://wikicreole.org/wiki/Talk.GenericExtensionElementProposal (2016-02-11)
    Open archived version from archive



  •