(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-20) was last changed on 26-Sep-2007 12:34 by ChuckSmith  

This page was created on 08-Mar-2007 11:03 by YvesPiguet

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 70 added 34 lines
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 the other hand, the "greedy nowiki" rule doesn't handle one special case. I think we should discuss this.
** Escape character should at least work with all the characters that are used for markup -- and no matter whether they are really part of a markup sequence or not. To simplify the rule, we can say "all non-alphanumeric characters". To simplify it even more, we can include all characters.
* Mechanics
** The escape character itself is not rendered.
** The character immediately following an escape character is rendered as is and is never considered part of wiki markup.
** Newlines immediately following an escape character are rendered as forced line breaks.
** To have the escape character rendered literally, escape it -- that is, use double escape character.
** Escape character is never part of any other markup -- like signatures (tilde) or forced line breaks (backslash), even tripled, quadrupled, etc.
Now, this leaves some room for decissions, the important ones being whether to honor it in nowiki, whether to include alphanumerics and which character to use -- tilde or backslash. All of these have their consequences, some desired and some not. Note, that if we decide to use backslash, we have to give up the current "forced new line" markup -- although we are getting another markup for forced new lines for free anyways.
Do these rules make sense to you? What do you think?
-- [[Radomir Dopieralski]], 2007-Apr-28
The current "forced new line" markup works well inside lists and tables etc. It would be a shame to lose that feature.
Any escape sequence adds complexity to the parser, the current escape sequence specification adds it considerably.
Do we really need an escape character? Perhaps this is a stupid idea, but could placeholders which contain a single character be reserved for displaying the character inline? For example: {{{<​<*>​>}}} would display *. It simply breaks the character sequence for the parser. Like Radomir's earlier nowiki suggestion, but easier to type and the character does not become monospaced.
-- [[Mark Wharton]], 2007-04-29
I like Radomir's mechanics ("The character immediately following an escape character is rendered as is and is never considered part of wiki markup.") because they are simpler to implement than the existing proposal. The existing proposal would require me to double all the rules in my parser, and adds a special requirement for anybody adding a new rule to the parser. Yuck! I also think that inside a preformated and nowiki block, the escape character should have no effect unless it affects the closing sequence.
-- AlexSchroeder
Version Date Modified Size Author Changes ... Change note
20 26-Sep-2007 12:34 8.109 kB ChuckSmith to previous restore
19 26-Sep-2007 02:33 8.164 kB 200.31.42.3 to previous | to last
18 26-Sep-2007 02:33 8.142 kB 81.180.65.2 to previous | to last
17 26-Sep-2007 02:32 8.126 kB 60.32.219.68 to previous | to last
16 06-Jun-2007 13:03 8.109 kB 84.75.118.101 to previous | to last The existing proposal is harder to implement.
15 06-Jun-2007 12:59 7.948 kB 84.75.118.101 to previous | to last I like Radomir's mechanics
14 28-Apr-2007 18:24 7.573 kB MarkWharton to previous | to last considerably complexity
13 28-Apr-2007 10:57 6.911 kB RadomirDopieralski to previous | to last sanity checks
12 04-Apr-2007 23:45 4.436 kB Gregor Hagedorn to previous | to last Simplify tilde rules!
11 04-Apr-2007 10:41 3.815 kB YvesPiguet to previous | to last Against weakening escape character
10 04-Apr-2007 09:25 3.093 kB 62.12.165.34 to previous | to last Hm, then we need to rewrite that proposal.
9 04-Apr-2007 06:38 2.551 kB ChristophSauer to previous | to last only escapes in certain combinations
8 04-Apr-2007 00:01 2.246 kB 84.75.130.155 to previous | to last ~/bin and /bin are not the same thing at all
7 03-Apr-2007 23:59 2.032 kB 84.75.130.155 to previous | to last For me, the most aggravating part is that ~ stands for the home dir in shells.
6 13-Mar-2007 15:09 1.822 kB ChuckSmith to previous | to last removed comments about moving comments
5 13-Mar-2007 15:00 2.038 kB 150.254.78.41 to previous | to last moved a misplaced comment here
4 13-Mar-2007 11:29 1.384 kB YvesPiguet to previous | to last Consequences -> request
3 13-Mar-2007 10:14 0.976 kB ChuckSmith to previous | to last why removed consequence
2 08-Mar-2007 12:31 0.648 kB YvesPiguet to previous | to last Nonbreaking spaces
1 08-Mar-2007 11:03 0.438 kB YvesPiguet to last Detailed proposals
« This page (revision-20) was last changed on 26-Sep-2007 12:34 by ChuckSmith