Talk

This is version 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Good for everything likely not of importance anymore in two days

You can always move interesting conversations to a page with an appropriate title later. It's a wiki ;)

Putting in titles for day-entries helps finding back things easier. New day-entries below this line, please.

---

2007-Apr-17#

Hi, I am currently working for Dirk Riehle at SAP. When I wanted to use the Creole markup language, I had some issues I couldn't figure out what the specification requires. I will try to make it short and it would be great if you can me a reply if I am right or wrong

1. If I want to print two bold asterisk in the wiki page, I cannot write "** ** **", because the second asterisk-pair is already the closing tag? So it is intended to use the next (not escaped) tag to close the bold section?
   But I can't rely on the use of in-line nowiki "** {{{**}}} **" because this could render two monospaced, or maybe not monospaced asterisks (depends on the implementer)? Is there any other possibility at the moment?
2. Creole uses CamelCaseWords for internal links (even without using the link tags "[[...]]")?!
   If the page name has not this notation, then it's necessary to use the link tags [[ and ]] ? Can you prevent a Camel-Case-Word to be automatically transformed to a link?

If there is no possibility to escape (multiple) characters in Creole, I would tend to suggest an escape character or a not monospaced in-line nowiki (e.g. 4 curly brackets for not monospaced, and 3 curly brackets for the still useful monospaced in-line text). But that’s not the topic right now.

Thank you very much for your support!
-- Martin Junghans, 2007-Apr-17

Both are currently being rejected in Creole0.6Poll. I agree with you.

-- YvesPiguet, 2007-Apr-17

Hi Martin,

1. There are two proposals that try to address this issue, either the Require Space After Bullet Proposal or the Hyphen List Markup Proposal. So far there is no consensus which one to use.
2. What wiki engine/creole renderer are you using? Creole does not define camel case. This wiki does use CamelCase, but it's because it uses Mixed Mode. There is however a Escape Character Proposal. This common character also would help wikis that allow camel case to escape camel case links.

You also might take a look at the Proportional Font Nowiki Proposal. As Yves said, we don't have agreed on them yet, so please read through those proposals and then give us your opinion on the Creole 0.6 Poll, and tell Dirk that his vote is very much appreciated there, too ;-)

-- Christoph Sauer, 2007-Apr-17

I hate to butt in, but how is the list markup related to the escaping of bold markup?

Another thing: can you really distinguish a monospace asterisk from a proportional one? I, for one, can't.

There is a hack that allows you to write double bold asterisk without making it monospace, but it's not intuitive and doesn't look good in the raw text: ** *{{{}}}* __

-- Radomir Dopieralski, 2007-Apr-17

Hi Christoph,
I want to implement a own simple renderer using the Creole standard only. So I have to consider all these special cases and ambiguities. Thanks for all replies, now I know that the reason is not a weak specification, but has to be discussed for a future implementation. Thank you! I will state my point of views later in the proposal pages.
-- Martin Junghans, 2007-Apr-17

---

2007-Apr-14#

I'm not sure where to put this, so I'll mention it here. So far we have focussed on making Creole easy for the users to write in and relatively easy to parse (mainly convert from Creole to HTML and other markups). But there is also a second aspect, one that also is an indication of how clear and well defined the language is: the possibility and ease of converting to Creole from various popular markups. This will be needed to migrate wikis. It will be needed for wiki engines that use WYSIWYG editors. It's also a good test on how well defined and streamlined the markup is. Note that this doesn't mean that Creole should have all features that HTML offers, of course.

-- Radomir Dopieralski, 2007-Apr-14

Escape characters will help there (see Nyctergatis sandbox with Creole output).

-- YvesPiguet, 2007-Apr-14

Not if they use "heuristics" or come together with insane markup -- then you'd have to escape practically every "hot" character, making the result totally unreadable for humans.

-- Radomir Dopieralski, 2007-Apr-14

That's definitively not what I want. NME could probably be smarter for its Creole output, but using nowiki instead of escape char is much worse.

-- YvesPiguet, 2007-4-14

2007-04-04#

I like pie, but I'm a little concerned about the sampling of wiki engines used to make those charts. I noticed that every chart uses a different set of wiki engines to compare against -- what are the rules of choosing them? Shouldn't the sample set be uniform?

I started making the No Wiki Markup Comparison and I understand perfectly how hard it is to collect information about markup on wikis -- that's why I'm listing the engines that are on WikiMatrix, but that I failed to collect information about (they lack documentation, their site is down or otherwise unusable, they only use a WYSIWYG editor).

I know that the collected statistics are not biased on purpose and that it's technical and/or organisational difficulties that rule the choice of engines, but at the same time I think we should play it safe and don't lie when we don't have full info.

-- Radomir Dopieralski, 2007-Apr-04

Thanks Radomir. Yes, the charts should be uniform. And if it is impossible for some reason (e.g. because some engines don't support some markup) there should be at least an explanation why the charts are not uniform. Chuck, could you add this please?

-- Christoph Sauer, 2007-Apr-10

2007-02-25#

Gregor Hagedorn I found this resource today and looked through it, being a content rather than system person. I like the ideas and hope this wins more support. I do not understand what is intended with Placeholder on Creole 0.5, please elaborate. I wrote Levels of Interoperability, please someone link it in - or ignore if out of scope - I cannot find a good parent place. I wrote a list of some markup wishes and comments on my personal page.

2007-02-22#

Christoph Sauer Dear creole parser developers. We have proposed a HyphenListMarkupProposal. I know that it is quite yet another change, but I think it's crucial. Please read through it carefully before you rant at me, because that was Chucks first response as well ;). I consider this as an important decision towards a Creole version 1.0. If we have sorted this out I feel pretty much that we are through.

My personal todolist/whishlist towards a Version 1.0

• getting through the HyphenListMarkupProposal discussion.
• general escape character (clarify usage of spaces before elements), see Escape Character Proposal
• clarify the usage of placeholder, discuss separate markup for placeholder and plugins/extensions/macros (term is engine specific) see confusion in Remove Placeholder Proposal.