(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 

Add new attachment

Only authorized users are allowed to upload new attachments.

This page (revision-108) was last changed on 24-Sep-2008 09:01 by 217.218.168.100  

This page was created on 03-May-2007 01:01 by 84.150.67.149

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 1 changed one line
&I have been thinking more about escape. I have started leaning towards the ;Escape character should be core" idea (in conjunction with "Escape character should escape a single character" and "Escape character should be ~"). I think it fits well with any future expansion of Creole. However, my real concern is what to do with preformatted block content and external links containing escape characters which are not rendered in the final output. For me, escaping whole Creole markup sequences is not a broad enough solution and imposes hidden constraints and limits future expansion. It was an excellent idea, but I don't believe it's the right way to go. Either we have all or we have nothing.
I have been thinking more about escape. I have started leaning towards the "Escape character should be core" idea (in conjunction with "Escape character should escape a single character" and "Escape character should be ~"). I think it fits well with any future expansion of Creole. However, my real concern is what to do with preformatted block content and external links containing escape characters which are not rendered in the final output. For me, escaping whole Creole markup sequences is not a broad enough solution and imposes hidden constraints and limits future expansion. It was an excellent idea, but I don't believe it's the right way to go. Either we have all or we have nothing.
At line 3 changed one line
In the meantime, the simple escape mechanism proposed here for preformatted blocks, I believe, is both adequate and safe. If we don't end up with an escape character then this is the best alternative, without a doubt. Having said that, I will endeavour to work through my escape thinking over the next few weeks and input into any escape arguments.
In the [[meantime]], the simple escape mechanism proposed here for preformatted blocks, I believe, is both adequate and safe. If we don't end up with an escape character then this is the best alternative, without a doubt. Having said that, I will endeavour to work through my escape thinking over the next few weeks and input into any escape arguments.
At line 253 added 411 lines
3) The current ways to do it inline are with two consecutive inline nowikis or with the escape character outside nowiki.If you support a more general escape mechanism in nowiki, you either need to escape the escape character itself (painful since tildes are common in many programming languages and nowiki is especially well suited to code fragments) or to have more exceptions. I much prefer the current rules.
-- [[YvesPiguet]], 2007-Jun-14
I don't like the way wikis which don't support camelcase autolinks should still recognize camelcase words following tildes. I suggest the following rules:
//Outside nowiki, preformatted, and URL, the escape character only escapes the character immediately following it, provided that it is not a blank (space or line feed).//
//The escape character disables the automatic conversion of URL to links and any similar mechanism supported by the wiki engine (camelcase wikiwords, copyright sign, etc.)//
Unix paths where the tilde usually represents the home directory would have to be escaped, but this is not a big problem since they're likely to be put in inline nowiki anyway. And we can't be expected to handle automatically all situations where some syntactic construct of a language or shell might collide with Creole.
-- [[YvesPiguet]], 2007-Jun-14
Escaping an url is easy: {{{http~://something}}}
-- [[Michele Tomaiuolo]], 2007-06-14
-----------
Yves, I modified your add to the "Escaping Nowiki". I agree that it is useful to not use tilde in nowiki to escape, but using a completely different mechanism now that we have a general escaping mechanism agreed upon feels odd. I think saying: Tilde does not escape in nowiki except with use on three closing curly braces is much simpler to understand, furthermore it is not new: JSPWiki uses it.
-- [[ChristophSauer]], 2007-Jun-16 14:48 (CEST)
Michele, the URL escaping via {{{http~://}}} may work but it is not very intuitive. I personally like the rule that a tilde in front of a link (i.e. a URL or a ~WikiWord) disables the link behavior.
Two address Yves' concern about the current recommendation that engines not supporting ~WikiWords should still recognize them: I think that engines whether or not they support ~WikiWords should behave equally. But maybe we could cover these cases in a general way by a slight change to the escape rule. Why not saying that a tilde at a beginning of word always escapes. If it is a link, then the tilde will additionally disables the link behavior...
-- [[OliverHorn]], 2007-06-16 16:33
//using tilde with three closing curly braces as an exception simplifies rules//: no, because then you must escape the escape sign; and we had already limited the escape scope to a single character.
What's wrong with the previous rules? (greedy nowiki and leading spaces)
-- [[YvesPiguet]], 2007-Jun-16
I would tend to agree with Yves here and would like to change it back where a leading space before the triple curly quote escapes it. Would anyone object to going back to this way of escaping the end of a nowiki block?
-- [[ChuckSmith]], 2007-Jun-16
Chuck, I have no objection whatsoever. The greedy nowiki and leading spaces rules are my preference. These two rules, as presented in [[AddNoWikiEscapeProposal]], allow the most flexibility with minimum side effects. It is the natural complement to an escape character everywhere else. There is the one special case, as Oliver points out above //"3. Closing braces in (inline) nowiki"//. However, this can be accomodated by closing the (inline) nowiki and immediately opening a new (inline) nowiki. An optimizing parser could even factor this in to produce seamless one span nowiki output, if it is considered an issue.
-- [[MarkWharton]] 2007-06-17
I agree, too. The changed rules seem to be broken because there is no way to escape the tilde itself (but that's needed if it is used as escape character).
Yves' suggestion for the inline nowiki (with greedy rule) to do it with two consecutive inline nowikis is fine for me.
-- [[OliverHorn]] 2007-06-17
Christoph, I restored version 26 because I'm concerned that the escape character for nowiki (preformatted) is getting off track. What you're proposing doesn't work and you're also making small changes here and there without considering the impact to the other areas of the document. It's not a criticism of you so please don't be upset. I'll be travelling in the next couple of days and wanted to reset things around the agreed solution before heading off. I admit it's a little harsh and not like me to restore a version like this. However, I believe the general opinion here is that the greedy nowiki and leading spaces rules are the correct solution and so we should be working more with that. If I'm wrong then please accept my apologies and restore to a later version. Hopefully see everyone in the planned IRC meeting on Tuesday night (my Wednesday morning).
-- [[MarkWharton]] 2007-06-18
So what do we decide about [[Multiline List Items]]? It seems there are very few wiki engines
supporting multiline paragraphs but not multiline list items.
Anyone opposed to the proposal?
-- [[YvesPiguet]], 2007-Jun-18
For the nowiki escape: Whatever. What do you mean by "multiline paragraphs"?
-- [[ChristophSauer]], 2007-Jun-18 21:53 (CEST)
Wiki-like line breaks which were chosen for Creole (see [[ChangeLinebreakMarkupProposal]]).
The same rule would apply to list items.
-- [[YvesPiguet]], 2007-Jun-18
I am indifferent to [[Multiline List Items]], and am afraid it might break some existing wikis when they introduce Creole into them. I know Alex Shroeder is for this change, but don't know how others stand. Any other opinions on whether we should introduce this into Creole 1.0?
-- [[ChuckSmith]], 2007-Jun-19
I don't find the way the escape character is described very satisfactory (I mostly agree on the
mechanism). What about what I proposed above on Jun 14th (remove alphanumeric exception,
but add a single exception for URLs)? What I wrote about paths isn't very relevant, because the
most common use of tildes there is before a slash where it would need to be doubled anyway,
not before a username.
Should we add this to the agenda for tonight?
-- [[YvesPiguet]], 2007-Jun-19
I'm not sure about the change. However, the removal of the alphanumeric exception will also solve the ~WikiWord escaping problem: A tilde at the beginning of a word will always escape the first character and hence the behavior is independent of the engine's support for ~WikiWords. (We still need the rule that the tilde disables the linking behavior.)
-- [[OliverHorn]], 2007-06-19
Isn't it the same? The point is to solve wikiwords, urls, and engine-specific autoconversion
(smileys etc.) simultaneously.
-- [[YvesPiguet]], 2007-Jun-19
I didn't propose the alphanumeric exception so I am not sure why this exception was initially made. I favor a general rule which covers all these problem cases, so nothing against the change from me.
Multiline list items: I like the idea behind it, but it creates another [[BoldAndListsAmbiguity]] ambiguity: How do you distinguish a 2nd level list item from a 1st level list item continuation starting with bold?
-- [[OliverHorn]], 2007-06-19
I've made the escape modification we discussed earlier this morning (CEST), trying to be clearer (//The following character is rendered as is and cannot be a part of any Creole markup//).
I think the escape character section should come immediately before or after the section on nowiki.
-- [[YvesPiguet]], 2007-Jun-20
Have you ever talked about invisible text (comments)? I think it may be useful to have this. What do you think?
-- Martin Junghans, 2007-06-24
I agree, but it's probably too late. You can have a plugin for that:
{{{
<<! comment >>
}}}
Plugins will also be required for metadata.
-- [[YvesPiguet]], 2007-Jun-25
I'm back online with some time to talk. Sorry to miss the meeting last week, it looks like it went reasonably well (I read through the log). Unfortunately, I wasn't able to get a connection. I'm still travelling but will be back into my normal routines (and desk ;-) by the end of this week.
I logged in yesterday to vote, but in the process of cleaning up some spam, I was blocked...
# Herb says you look like a spammer, and I trust Herb! (Incident code GLVNGU)
# You have been temporarily banned from modifying this wiki. (1765 seconds of ban left)
Needless to say, I didn't try to cleanup any spam today.
-- [[MarkWharton]] 2007-06-26
Perhaps comments (i.e. invisible text) would be something to put in [[Creole Additions]].
-- [[ChuckSmith]], 2007-Jun-26
The note I wrote about //Closing braces in nowiki// should be removed when it becomes obsolete (when the wikicreole engine
gets creole-compliant), before 1.0 is "released".
-- [[YvesPiguet]], 2007-Jul-4
I just corrected the display of the "Escape Nowiki" using the JSPWiki escape syntax, since the CreoleFilter does not support the syntax as proposed. I'll change it as soon as the Creole 1.0 changes are implemented.
-- [[ChristophSauer]], 2007-Jul-05 11:02 (CEST)
At first I was pretty excited that somebody finally managed to reach an agreement on a common wiki markup. I'll probably adopt it for my Wiki anyhow. But still I'm somewhat concerned about its dead end status.
The 1.0 specification explicitely says "frozen" and "no development for two years". And ultimately, there couldn't be any - after full two years of no-moving. So if there's no chance for a 1.5 or ever seeing a Creole 2.0, won't Wiki markups drift apart again sooner or later? I'm uncertain that //Creole additions// are going to cut it.
Surely that decision stems from not wanting to implement a moving target (0.1, 0.4, 0.6, 1.0, ...). But why exactly did Creole had to go **frozen**? That somehow has a little no-progress sound to me, atm.
-- Mario, 2007-Jul-11
I agree. I don't know if, when, and by whom it was discussed openly. I don't know why the last scheduled irc talk was cancelled at the last minute either.
-- [[YvesPiguet]], 2007-Jul-12
In the sense of feature freeze, a [[goal]] stated in the wms markup workshop: "Stable for the next three years". We changed that into two, and of course I agree that if it turns out that there are deficiencies in the core we will address them together immediately (I mean real interoperability problems, not something that was already discussed). But now it's time to give developers the certainty that they don't have to change something all the time, that for them is not a core feature. It's time now to collect experiences in the real world, instead of endless discussions what might be good or bad. Feel free to add your opinions on the talk pages, and make suggestions and improvements under [[Additions]].
irc talk was canceled due to lack of interest (according to Chuck), but I would be happy if we could have one again on the topic of [[Promotion|promoting creole]].
-- [[ChristophSauer]], 2007-Jul-12 13:52 (CEST)
I agree with what Christoph said and just want to add that there can be discussion about Creole 2.0, but we don't want to change the spec, unless there are real shortcomings before a two year period is over. I cancelled the IRC meeting, because it seems like we were going to have a meeting for meeting's sake, instead of meeting to discuss real issues. Also, it was conflicting with the monthly WikiOhana meeting. However, we are planning to host another IRC meeting soon on promoting Creole.
-- [[ChuckSmith]], 2007-Jul-12 14:43 (CEST)
Ok, thanks. I think future evolution should preserve compatibility as much as possible; that's why I'm happy with the last decisions,
because it was the last moment to make them. But on the other hand, the term "frozen" might discourage new developers, because
long-term congelation is a little too close to death: it could be difficult to restart fruitful discussions in 2009.
Meetings risk to be less active during the holiday season...
-- [[YvesPiguet]], 2007-Jul-12
It was a pity I missed the 03 July meeting, anyway if I could be there I wouldn't have done more than lurking because I am relatively new to Creole in general. I also think that it would be better to say that "discussion and modifications" to the Creole spec are currently on hold, instead of the set amount of time of 2 years which can be an epoch in the IT world.
Also, shouldn't the specification change (I know that this democratical concept conflicts with the "moving target" issue and creates a paradox) when more people (let's say for example, in the case that the number of people interested doubles) join? That's why I am generally against a "frozen" idea: it is something that mature projects can do, WikiCreole is a high-quality project but it is not yet so widespread to make such choices (in my humble opinion). I know that having it "frozen" will help developers to catch with it, but was it the correct choice from the marketing point of view? (please no flames, I am new here and I am respectful to this great project and the work that other people have done up to now!)
Most probably there isn't a yes/no answer, a compromise had to be done, in such case please excuse me for moving around the dust
-- [[DanieleC.]], 2007-Jul-12
Daniele, you are right. "Frozen" is the wrong term here. I changed it to your suggested phrase. Thanks!
-- ~~~~
Glad to give some help :)
-- [[DanieleC.]], 2007-Jul-14
It would be even better to say why Creole is on hold on the home page of wikicreole; otherwise, new visitors might think
there is some major problem which needs a solution (technical issue? conflict between contributors? lack of interest?)
If you don't want these details on the home page, the fact that the specification is on hold could be moved elsewhere,
such as in [[Versions]] (where the word //frozen// should be replaced anyway for the sake of consistency).
-- [[YvesPiguet]], 2007-July-17
Hello, not quite sure of how/where corrections should be sent.
There appears to be a conflict between the line break section and the list section.
From the Line break section
{{{
Recommended XHTML:
* This is a single list item
followed by a paragraph?
<ul>
<li>This is a single list item</li>
</ul>
<p>
followed by a paragraph
</p>
}}}
First note, that the "?" is missing from the XHTML (and the use of "?" here is a bit confusing).
More importantly, this seems to contradict what is in the list section:
{{{
A list item ends at the line which begins with a * or # character
(next item or sublist), blank line, heading, array, or nowiki block;
like paragraphs, it can span multiple lines and contain line breaks
forced with \\.
}}}
To me, "span multiple lines" implies that
{{{
* foo
bar
new paragraph
}}}
should render to
{{{
<ul>
<li> foo
bar</li>
</ul>
<p>
new paragraph
</p>
}}}
Other note: what is an "array" block? I don't think this term is used previously or anywhere else.
What is the correct list element processing?
# Close list element at end of line (from Line Break section)
# Close list element when new list element is found, or when a block element is encountered (e.g. table, heading, hr, paragraph) (from List section)
thanks all
-- [[NickGalbreath]], 2007-July-17
Thanks for your remarks; I've removed the example in the line break section (no more valid with multiline list items), and
I've replaced "array" with "table" (my fault). I hope it's fine to fix these mistakes in 1.0; otherwise, there should be revisions
(1.0a, 1.0b, etc.).
List items can span multiple lines.
-- [[YvesPiguet]], 2007-July-20
Excellent. Thanks Nick for the remarks! Yves, I trust you so it's fine if you fix mistakes in 1.0. I wasn't able to do so the last few days. Nick, the multiline list items came in quite late, see [[26JunMeeting]] and [[Creole 1.0 Poll]], so I guess we overlooked to change the mentioned rule in the spec.
-- [[ChristophSauer]], 2007-Jul-24 06:03 (CEST)
This discussion page is much too long. If there has been some consensus that condensed into creole 1.0, the old discussion here should be moved to some archival page and this discussion page should be about creole 1.0 as it is.
The main page also has some contradictions in the change notes vs. the main spec. text and should be cleaned up:
* escape char
** The spec section should mention "The escape char is the tilde (~)." Currently you can only guess it from the examples.
** The change notes talk about "the escape character" at one place and about "tilde" at another place. This should be changed to "the escape char" at both places if this was the intended meaning.
** The change note "removed escaping closing nowiki triple curly brackets because this is now covered by the escape character" is unclear (removed WHAT escaping?) and contradicts the spec section about "Closing braces in nowiki" (the latter one says "lines with three closing braces which belong to the preformatted block must follow at least one space"). Decide, do we now use "~}}}" to escape or " }}}"?
For people not knowing mediawiki, the placeholder stuff is unclear.
-- Thomas Waldmann, 2007-08-09
I've moved Thomas remarks at the end to keep chronological order.
I agree with all your remarks. Thanks! I'd also move the list of changes at the beginning of [[Creole 1.0]], because they're irrelevant
there in what should be a reference document.
I've made the changes you propose, except for //the escape character" at one place and about "tilde" at another place// which
I'm not sure to understand."Removed escaping..." is obsolete; I've removed it.
The placeholder is unclear to many people. An implementation which uses it would be helpful to evaluate it. I guess it could
contain a number which would refer to a table of unsupported stuff when converting from some richer markup language like
mediawiki, to permit restoring them when saving modifications. Whether it would be practical is an open question to me.
I leave the decision to move this discussion or the list of changes to somebody else.
-- [[YvesPiguet]], 2007-Aug-9
Creaole and other wiki-syntaxes like it really fall short if you have lots of external (and therefore often long) links. This is especially the case when using Creole as a Blog-Language, or when writing scientific documents (or other texts where you have to carefully cite your sources).
Therefore it would be great if the parsing rules could be relaxed a bit, so that if a link with description has the link at the second position and the first is clearly not a link, it still gets shown sensible.
That would help greatly.
-- [[http://häcker.net| Martin Häcker]]
What's the problem?
-- [[YvesPiguet]], 2007-Sep-20
how would additional links like the ones used in http://trac.edgewall.org best fit into creole? --ThurnerRupert
Which additional links?
-- [[ChuckSmith]], 2007-Okt-17 15:08 (CEST)
What about underline and strikethrough?
-- Mo 2008-Mar-14
Underline is an [[CreoleAdditions|addition]]. Strikethrough is not defined (yet?). It's been discussed at different places, though; do a search for "strike".
-- [[YvesPiguet]], 2008-Mar-16
== Self-contradiction in escape character
I find it self-contradicting or at least ambiguous. On one hand, it says, that escape character escapes just the following character, i. e.
{{{
~http://localhost
}}}
should be rendered as
{{{
http:<em>localhost</em>
}}}
On the other hand it says a tilde escapes the whole URI.
It is obscure, whether
{{{
~** bold ** text
}}}
should be rendered as
{{{
** bold ** text
}}}
(escaping the whole pattern, as an URL) or
{{{
** bold <strong> text </strong>
}}}
If escaping URI as a whole is an exception, it should be explicitly marked as such.
-- [[IvanFomichev]], 2008-04-04
In front of something which is converted automagically, such as a URL (but not explicit markup), it prevents the conversion. Elsewhere (except in nowiki, preformatted and inside URL, or in front of a blank), it escapes a single character.
-- [[YvesPiguet]], 2008-04-04
The EscapeCharacterProposal is somewhat different from the final spec. I don't like ~~ in URLs be considered escapes. They are common in user URLs and there is no need escaping a character that is not considered special by Creole.
* {{{http://example.org/~user/}}} -> http://example.org/~user/
On this Wiki, ~~ escapes the URL, but the URL is parsed as inline text:
* {{{~http://example**.org**/~user/}}} is rendered ~http://example**.org**/~user/
* {{{~http://example//.org///~user/}}} is rendered ~http://example//.org///~user/
Another test; Creole formatting inside URLs:
* {{{http://example//.org///~user/}}} -> http://example//.org///~user/
* {{{http://example**.org**/~user/}}} -> http://example**.org**/~user/
-- [[LarsChristensen]], 23-May-2008
Please don't consider what this wiki is doing to be "the final spec". The implementation isn't perfect. You've pointed out a few deficiencies here for sure. Tildes in urls are fairly common and Croele should treat them as any other character.
[[http://werkzeug.pocoo.org/e/simplewiki/tildes_in_urls|This wiki]] uses Creole and it does a better job with your tests. ;)
-- [[StephenDay]], 23-May-2008
= Example with two opening braces? =
The current (12-May-2008) page gives the following example for inline NoWiki markup:
{{{
{{if (a>b) { b = a; }}}
}}}
There are only two opening braces. Is that intentional?
-- [[Ben Kovitz]], 12-May-2008
The parser is having trouble with this. There should be three opening braces and four closing ones.
An admin needs to unlock the page to fix it (or add a comment that it is not displaying correctly).
-- [[StephenDay]], 13-May-2008
Thanks for the clarification. I'm implementing the ~{{{ just as a token, and not bothering trying to match up braces inside the Nowiki text with any braces that occur before the ~}}} appears.
-- [[Ben Kovitz]], 13-May-2008
== Use of TT tag for representing code
For code rendered using the {{{{{{ }}}}}} technique, would it not be better for the markup to be <code></code> tags rather than <tt></tt> tags, as the former gives semantic meaning and allows the browser to choose an appropriate font, wheras the latter is simply a display tag?
-- M1ke, 18-May-2008
Creole doesn't specify that <tt></tt> be used, it's just a suggested implementation. <code> could be used, as could <span>, or no markup at all (or whatever).
-- [[StephenDay]], 18-May-2008
Version Date Modified Size Author Changes ... Change note
108 24-Sep-2008 09:01 47.251 kB 217.218.168.100 to previous
107 24-May-2008 21:26 47.247 kB 24.201.230.79 to previous | to last escape characacter in url answer
106 23-May-2008 19:53 46.839 kB 212.242.206.149 to previous | to last Escape characters in URLs considered bad
105 19-May-2008 14:58 46.067 kB StephenDay to previous | to last answer
104 18-May-2008 17:23 45.863 kB 89.242.167.236 to previous | to last Added discussion on TT tag
103 14-May-2008 08:30 45.52 kB BenKovitz to previous | to last Thanks for the clarification
102 13-May-2008 20:11 45.29 kB StephenDay to previous | to last answer
101 12-May-2008 22:45 45.05 kB BenKovitz to previous | to last Is the example with two opening braces correct?
« This page (revision-108) was last changed on 24-Sep-2008 09:01 by 217.218.168.100