MoinMoin: attachment:moin_markup_ideas_irc_29apr05.txt of UnifyMarkup

   1 09:22 < nir> Fabi, do you have any problem with addition of section call to
   2 the formatter interface?
   3 09:23 < nir> its needed by SlideShow, SectionParser
   4 09:23 < Fabi> infact the RC macro has changed a lot in 1.4, too
   5 09:23 < Fabi> what should this call return?
   6 09:23 < nir> in html, a div with attribtues
   7 09:23 < nir> in text, probably nothing
   8 09:23 < Fabi> hmm
   9 09:23 < nir> in xml, probably <section>
  10 09:23 < nir> with attribtues
  11 09:24 < nir> its like startContent
  12 09:24 < Fabi> I don't know enough about this section thing to come to a
  13 desicion
  14 09:24 < nir> but that one has only id
  15 09:24 < nir> #!section simply put rendered markup inside a div
  16 09:25 < nir> then this div can be designed by css
  17 09:25 < nir> for example a floating sidebar
  18 09:25 < nir> or floating image
  19 09:25 < nir> or part of a document with special meaning
  20 09:25 < xorAxAx> i think it is quite harmless
  21 09:26 < xorAxAx> and it doesnt break any api (like other suggestions :))
  22 09:26 < starshine> like an included page tidbit even, with this in charge of
  23 the floatiness?
  24 09:26 < nir> we have to add this to all formatters
  25 09:26 < nir> or at least to the base
  26 09:27 < nir> we need also span
  27 09:27 < nir> currently the only way to create a span with some attribtues is
  28 by code_token
  29 09:27 < starshine> could we use this to float code sidebars? I'd think so
  30 09:28 < nir> it will not work for code
  31 09:28 < starshine> awww
  32 09:28 < nir> since you can't nest {{{}}}
  33 09:28 < nir> also code tend to be wide
  34 09:28 < xorAxAx> i suggested a protocol to solve that issue
  35 09:28 < starshine> oh, first }}} would close wrong :/
  36 09:29 < starshine> but you could use include to do it; code example on other
  37 page?
  38 09:29 < nir> include works if you need it
  39 09:29 < nir> also inline:
  40 09:29 < starshine> so that'd be yes, after one level of indirection :)
  41 09:30 < nir> inline is a very good solution when you have code you want
  42 people to download anyway
  43 09:30 < starshine> screen's man page says: A weird imagination is most
  44 useful to gain full advantage of all the features.
  45 09:41 < starshine> inline shows it with a download link?
  46 09:41 < nir> yea
  47 09:42 < nir> the content, then a download link
  48 09:42 < starshine> cool
  49 13:48 < nir> there is a page about this
  50 http://moinmoin.wikiwikiweb.de:80/UnifyParsersAndMacros
  51 13:51 < Fabi> but there are still lots of undesided things
  52 13:51 < Fabi> and problems
  53 13:53 < nir> Fabi, you did not mention that on that page :-)
  54 13:54 < Fabi> most stuff is already on the page
  55 13:55 < nir> the last idea of [[]] for link and {{}} for include can be nice
  56 13:55 < Fabi> changin the markup is always and obiously critical
  57 13:55 < nir> but {{plugin:name}} is little long
  58 13:55 < nir> although not much long then http://
  59 13:56 < Fabi> it is too long for [[BR]]
  60 13:56 < nir> we don't like BR anyway
  61 13:57 < nir> in most cases its hack to overcome problems in our markup or
  62 the css
  63 13:57 < nir> or just misused
  64 13:58 < Fabi> I would use inline: as a keyword and provide a markup for
  65 plugins
  66 13:58 < Fabi> this make more sense IMHO
  67 13:59 < nir> so [[link]] [[inline:include]]
  68 13:59 < Fabi> as inline is used much less often
  69 13:59 < Fabi> or stick to the Include macro
  70 13:59 < xorAxAx> ThomasWa1dmann: no
  71 13:59 < xorAxAx> ThomasWa1dmann: feel free to try it :)
  72 14:00 < nir> so what will be the macro markup?
  73 14:00 < Fabi> .oO(some conversation is so slow that it is hard to follow...)
  74 14:00 < nir> and what about macros and parser unification?
  75 14:00 < Fabi> I would suggest using one markup for both
  76 14:00 < Fabi> may be {{PluginName(args) text}}
  77 14:00 < Fabi> and use [[ ]] for links
  78 14:00 < nir> so [[]] will be always links?
  79 14:01 < Fabi> yes
  80 14:01 < Fabi> if we change our markup we should try to move it more to the
  81 MediaWiki syntax
  82 14:01 < Fabi> which is not such different (if you ignore the HTML tags)
  83 14:01 < nir> so how do you add an image or attachment?
  84 14:02 < nir> and link to attachment or image?
  85 14:02 < Fabi> images and attachments will go away in 1.4
  86 14:02 < nir> of course they will not
  87 14:02 < Fabi> there will only be URLs and Pages
  88 14:03 < starshine> ha
  89 14:03 < Fabi> the question is if we stick to the autoinclution of images
  90 14:03 < nir> yea, but you still need a way to add either a link or the
  91 content of the link
  92 14:03 < starshine> I gave ideas for these to be described. to TW a while
  93 back.
  94 14:03 < starshine> and I *like* being able to stash images within my
  95 wikispace
  96 14:03 < nir> [[http://example.com/image.png]] should be a link
  97 14:04 < nir> same for [[Page Name]]
  98 14:04 < nir> and if you don't use http://example.com/image.png for the image
  99 include
 100 14:04 < Fabi> ok, so we could use [[include:http://example.com/image.png]]
 101 14:04 < nir> you need markup for include
 102 14:04 < nir> no
 103 14:04 < nir> [[]] is a link
 104 14:04 -!- J-PGuerard [tylor@JPG.fan.moinmoin] has joined #moin
 105 14:05 < nir> should never use for include
 106 14:05 < nir> that not consitent
 107 14:05 < starshine> I think display-as-link and display-as-inclusion should
 108 be the basis on which related wikimarkup is considered
 109 14:05 < nir> so we need markup for include, or use include macro
 110 14:05 < nir> or inline:
 111 14:06 < nir> but inline: is bad, we must avoid this markup
 112 14:06 < nir> unless we support inline:"name with spaces"
 113 14:06 < starshine> [http://url/is.here/ Name Title]  {http://url/is.here/
 114 included-thingy's headline}
 115 14:06 < nir> same for attachments
 116 14:07 < nir> thats the last idea on the unify page
 117 14:07 < Fabi> there are no attachments
 118 14:07 < starshine> I want attachments
 119 14:07 < starshine> I use them a lot
 120 14:07 < Fabi> no you don't
 121 14:08 < nir> there are pages which are files, or attachments
 122 14:08 < starshine> if you take away attachments you'll break my wiki
 123 14:08 < nir> we should use the old names if possible
 124 14:08 < starshine> Fabi: are you trying to tell me how I use my wiki??
 125 14:08 < Fabi> attachments already ahve page names
 126 14:08 < starshine> I mean, sure, my wiki isn't very big...
 127 14:08 < starshine> but I do use it.
 128 14:08 < nir> starshine, the idea is that attachment will be like a page
 129 14:08 < Fabi> starshine, we are talking about the internal implementation
 130 14:09 < starshine> oh ok. 
 131 14:09 < nir> from the wiki pov, attachemnt is just another page
 132 14:09 < nir> from the user view, its a file she uploaed
 133 14:09 < Fabi> and there is no reason to need the attachment: thing
 134 14:09 < nir> and want to include somewhere
 135 14:10 < nir> I think Include(name) can be used for all types of pages
 136 14:10 < starshine> what about pictures?
 137 14:10 < nir> or if we have a markup for include - then {{name}}
 138 14:10 < Fabi> will get pages if uploaded
 139 14:10 < nir> {{/picture.png}}
 140 14:11 < nir> can be a sub page which is a png image
 141 14:11 -!- drewr [~drew@drewr.active.supporter.pdpc] has quit ["home"]
 142 14:11 < nir> or {{FrontPage/Logo.jpg}}
 143 14:11 < Fabi> even without the / if you want to use it wiki wide
 144 14:11 < nir> include a sub page from another page
 145 14:11 < starshine> so I had suggested [[linkthings]] and {{inclusionThings}}
 146 with the idea of an extra character for what type
 147 14:11 < starshine> e.g. [[:  :]]  {{:   :}}  
 148 14:12 < nir> but you don't need that character
 149 14:12 < Fabi> I like :}}
 150 14:12 < Fabi> it looks funny
 151 14:12 < nir> its too perlish
 152 14:12 < nir> for type we should use clear names
 153 14:12 < nir> like http:
 154 14:12 < nir> mailto:
 155 14:12 < starshine> you only need types for things that act different enough
 156 people will want to mark them so
 157 14:13 < Fabi> about what differences are you talking about?
 158 14:13 < nir> but what is different?
 159 14:13 < nir> only macros I think
 160 14:13 < Fabi> .oO(hehe faster)
 161 14:13 < starshine> e.g. inclusion that's just an inclusion (attachment:
 162 Include() and possible others), vs. inclusion that also offers download
 163 (inline:)
 164 14:13 < nir> Fabi, you are closer to the irc server :)
 165 14:14 < nir> an image page can always offer a download link when you include
 166 14:14 < nir> while a text page will not
 167 14:15 < nir> another option is to have 3 markups
 168 14:15 < nir> [[link]] {{include}} ((macros))
 169 14:15 < nir> this will make lisp users happy :-)
 170 14:15 < Fabi> ((Macro(args)))
 171 14:15 < starshine> ooh and then you don't need parens around the macro's
 172 parameters? 
 173 14:15 < starshine> heh
 174 14:15 < nir> ((macro args))
 175 14:16 < starshine> I'm with nir, less typing's good
 176 14:16 < Fabi> .oO(we need a lisp plugin
 177 14:16 < starshine> lotsa insipid silly parentheses
 178 14:17 < nir> macro is always an include, but it save the extra word needed
 179 in {{plugin:include}}
 180 14:17 < nir> or use {{{macro}}}
 181 14:18 < starshine> {{{somemacro\n bla bla bla bla bla yak yak long stuff \n
 182 more stuff\n}}}
 183 14:18 < starshine> ^ ?
 184 14:18 < starshine> parser done this way is just a macro with a LOT of
 185 parameter, right?
 186 14:19 < nir> one big argument
 187 14:19 < starshine> can a macro tell if it was invoked square or curly style?
 188 14:19 < starshine> maybe macros could have their own methods for being told
 189 to be linkish or includes
 190 14:20 < nir> currently its totally different code
 191 14:20 < nir> you want to call a macro in a link?
 192 14:20 < nir> what is the result?
 193 14:20 < starshine> .o( we're scaring people off :)
 194 14:20 < starshine> welllllll depends on the macro I'd think
 195 14:20 < nir> lets say a macro return some html 
 196 14:21 < nir> how it can be a link?
 197 14:21 < nir> macro is always an include
 198 14:21 < nir> it can return a link
 199 14:21 < starshine> maybe I have a FindMeAPageWith macro, it might be able to
 200 return a hotlink in one case, some sample text of and *then* a hotlink in
 201 the inclusive mode
 202 14:21 < nir> but its "include the output of the macro here"
 203 14:22 < nir> but that means you need to have a markup for macro
 204 14:22 < starshine> people will want to define macro by intent :)
 205 14:22 < nir> like [[code:macroname]]
 206 14:22 < nir> and {{code:macroname}}
 207 14:22 < nir> cause [[name]] is a page
 208 14:23 < starshine> ok if something is a URL then "code:" there will look
 209 like (surprise) http:
 210 14:23 < nir> pages are the first class in a wiki
 211 14:23 < starshine> or maaaybe https:
 212 14:23 < nir> well thats was my suggestion
 213 14:23 < nir> name is a page
 214 14:23 < nir> macro:name or plugin:name etc. is a plugin
 215 14:23 < starshine> [[macroname:stuf as arguments]] changes soemthing from
 216 the http: handler to the whateveritis.
 217 14:24 < nir> but then your have {{plugin:BR}}
 218 14:24 < starshine> [[interwikithingy:pagename]] also seems to happen, right?
 219 14:24 < nir> everything can be represented as url
 220 14:24 < nir> type:data
 221 14:25 < Fabi> just as example:
 222 14:25 < starshine> might reserve [[unrecognizedwidget:bla bla]] for
 223 interwiki check, and leave {{unrecognizedwhatsit:bla bla bla}} as macro
 224 invocation
 225 14:25 < nir> can be {{run:BR}}
 226 14:25 < Fabi> WP uses [[Image:Name.png]] to include an image
 227 14:25 -!- DuckMaster [~Duck@dyn-83-157-148-56.ppp.tiscali.fr] has joined
 228 #moin
 229 14:25 < Fabi> and [[:Image:Name.png]] to make an link to it
 230 14:26 < nir> wikipedia?
 231 14:26 < Fabi> yep
 232 14:26 < nir> quite ugly markup
 233 14:26 < xorAxAx> Fabi: also known as mediawiki
 234 14:26  * Fabi agrees
 235 14:26 < xorAxAx> Fabi: dont confuse the evil guys
 236 14:26 < starshine> I would think... if we were to change anything.... we
 237 should make it so that things are easier to "just guess" - not to chase some
 238 other wiki type around.
 239 14:27 < Fabi> xorAxAx, I don't know if they really use a regular MediaWiki
 240 14:27 < xorAxAx> Fabi: sure
 241 14:27 < nir> we should change what is currently broken
 242 14:27 < xorAxAx> Fabi: just tweaked with thousands of caches
 243 14:27 < nir> and use most used markup of possible
 244 14:27 < Fabi> ok, images are normally included
 245 14:27 < nir> unless we have really much better one
 246 14:27 < Fabi> most other pages are normally not
 247 14:27 < Fabi> for including pages we can use an Include macro
 248 14:28 < Fabi> for including images we can not
 249 14:28 < nir> if pages and image are the same, we should use same markup
 250 14:28 < nir> I don't see any reason why including a page should be different
 251 than an image
 252 14:29 < xorAxAx> ACK
 253 14:29 < Fabi> I just want to sketch the use cases
 254 14:29 < starshine> "better" would be best, if I can do things like describe
 255 the reasoning of it across a phone without making people scratch their heads
 256 14:29 < xorAxAx> "we can use an Include macro" doesnt sound like a use case
 257 14:29 < starshine> if I can say "basically any of the square brackets
 258 mean..." then I'm ahead on that
 259 14:30 < Fabi> ok what about doing it the other way round as WP
 260 14:30 < Fabi> [[Name.png]] is a link
 261 14:30 < Fabi> [[:Name.png]] is an image
 262 14:30 < starshine> do we have a page to argue about possible wiki markup?
 263 14:30 < Fabi> [[:Name]] is an included page
 264 14:31 < nir> we can use this
 265 14:31 < Fabi> UnifyParsersAndMacros
 266 14:31 < nir> but its the same as [[link]] {{include}}
 267 14:31 < nir> [[: == {{
 268 14:31 < starshine> Fabi: for other types of mark besides macros though ?
 269 14:31 < Fabi> no because we need the { } for the macros/processors
 270 14:31 < starshine> ok
 271 14:32 < nir> but macros and parsers are includes also
 272 14:32 < Fabi> no
 273 14:32 < starshine> [[ thingies are direct code, really handled by moin,  {{
 274 things are addins?
 275 14:32 < Fabi> they are not
 276 14:32 < nir> they include the content of the macro
 277 14:32 < nir> the output
 278 14:33 < starshine> {{themeMyInclusionWeirdly:othertheme\nbla bla bla yak
 279 bla\n}} ?
 280 14:33 < Fabi> but they don't point to an external object which you can
 281 deside to linkto or include
 282 14:33 < Fabi> plugins are a different name space
 283 14:34 < nir> because you decided that [[]] is point to external object
 284 14:34 < starshine> ok so [[ is generate html and {{ is generate wikistuff to
 285 be further parsed?
 286 14:34 < nir> but [[is a link]]
 287 14:34 < nir> so we need 3 types of markup
 288 14:34 < Fabi> yes
 289 14:34 < starshine> [[is a link]] <- a non camel case page name :) people
 290 will enjoy that
 291 14:34 < Fabi> link, include and plugin
 292 14:35 < starshine> right, [[ {{ (( 
 293 14:35 < starshine> :D
 294 14:35 < Fabi> I don't like (( much
 295 14:35 < xorAxAx> starshine: why? ["it does already exist"
 296 14:35 < xorAxAx> ...]
 297 14:35 < nir> [[is better]]
 298 14:35 < Fabi> ["Sucks"]]
 299 14:35 < xorAxAx> yeah, easier to type
 300 14:35 < nir> looks better, easier to type
 301 14:35 < starshine> [[ same char is very easy to type
 302 14:35 < starshine> " is a shifted char
 303 14:35 < nir> [[[[[[[[[[[[[[[[
 304 14:36 < xorAxAx> but the difference is not that big
 305 14:36 < xorAxAx> starshine: [ is similar to a shifter char
 306 14:36 < nir> on german keyboard [ is hard no?
 307 14:36 < xorAxAx> starshine: on a german keyboard
 308 14:36 < xorAxAx> it is ALT GR + 8
 309 14:36 < starshine> keyboard may vary, but, I see " always shifted, [ usually
 310 not
 311 14:37 < Fabi> ok, is it consensus that we need 3 kinds of markup?
 312 14:37 < nir> I think its the best option
 313 14:37 < nir> just save typing
 314 14:37  * starshine wishes wikipedia had a keyboards of the world page like
 315 its flags of the world :)
 316 14:37 < xorAxAx> which 3?
 317 14:37 < nir> and you can see right away what its doing
 318 14:37 < starshine> welll... if he doesn't like (( ... << ?
 319 14:37 < nir> but you have to learn the meaning first
 320 14:38 < nir> 2 markups are easier to learn
 321 14:38 < Fabi> what about [[PageLink|Image.png]]?
 322 14:38 < nir> its better for spaces in names
 323 14:38 < starshine> heh, we could use <?Macro arg arg?> and it could look
 324 like php
 325 14:38 < xorAxAx> Fabi: how do you escape | in the names?
 326 14:38 < xorAxAx> starshine: or <% and let it look like JSP
 327 14:39 < Fabi> my point is not the |
 328 14:39 < starshine> but the same char would still be easy :)
 329 14:39 < xorAxAx> Fabi: what should it do?
 330 14:39 < Fabi> my point are image links
 331 14:39 < xorAxAx> Fabi: alias the link?
 332 14:39 < starshine> ok 
 333 14:39 < xorAxAx> Fabi: with a string or a link?
 334  * starshine digs out a decent browser for page editing..
 335 14:39 < nir> soruce|label
 336 14:39 < Fabi> an images that is a link to somewhre else
 337 14:40 < xorAxAx> that is not very intuitive
 338 14:40 < nir> why not
 339 14:40 < xorAxAx> in fact, you even have to remember the order
 340 14:40 < Fabi> but used quite often
 341 14:40 < xorAxAx> what if someone supplies 2 non-images?
 342 14:40 < starshine> Unify... um..
 343 14:40 < Fabi> the question is how to you see that the label is an image
 344 14:40 < nir> the first is the source
 345 14:40 < xorAxAx> nir: source?
 346 14:40 < xorAxAx> nir: he sketched it differently
 347 14:40 < nir> [[link]] [[link|with text]]
 348 14:40 < Fabi> xorAxAx, link target
 349 14:40 < nir> its very clear
 350 14:41 < xorAxAx> Fabi: target != source
 351 14:41 < starshine> .o( hope I remembr my pw
 352 14:41 < Fabi> href
 353 14:41 < xorAxAx> in fact, they are mutually exclusive
 354 14:42 < starshine> 3 results
 355 14:42 < nir> [:include:]?
 356 14:42 < starshine> Unify Pages And Attachments
 357 14:42 < starshine> Unify Parsers And Macros
 358 14:42 < starshine> Unify Parsers And Processors
 359 14:43 < Fabi> [[Pagename|[[Image.png]]]]
 360 14:43 < Fabi> [[Pagename|[[:Image.png]]]]
 361 14:43 < nir> ho
 362 14:43 < Fabi> [[Pagename|((Image.png))]]
 363 14:43 < nir> why the second [[]]?
 364 14:43 < Fabi> [[[[[[((((((]]]]]]|||||)))))
 365 14:43 < starshine> heh
 366 14:43 < Fabi> because it is an include
 367 14:44 < Fabi> and not plain text
 368 14:44 < nir>
 369 [[[[[[[[[[[[[[[[[[[[[[[[[[[[[((((((((((((((((()))))))))))))))]]]]]]]]]]]]]]]]]]]]]]]]]]]
 370 14:44 < starshine> why do you need two of it once you're inside the right
 371 delimiter
 372 14:44 < nir> yea, that suck
 373 14:44 < Fabi> [[Pagename|Image.png]] renders a a link with Image.png as text
 374 14:44 < nir> better to use a type: word
 375 14:45 < nir> [[Page|image:logo.jpg]]
 376 14:46 < Fabi> I see no reason why start with keywords at exactly that place
 377 14:46 < nir> because [[Page|[[Image.png]]]] is impossible
 378 14:46 < starshine> ugh
 379 14:46 < Fabi> why
 380 14:46 < Fabi> it's very rare anyway
 381 14:46 < starshine> ok these things seem to be about unifying the under the
 382 hood mechanism
 383 14:46 < starshine> and that's good
 384 14:46 < nir> more then one level of those [[ is hard to read
 385 14:46 < starshine> but unifying the markup...
 386 14:47 < Fabi> starshine, our markup is in urgend need to egt unified
 387 14:47 < nir> we already use keywords
 388 14:47 < Fabi> s/d/t/
 389 14:47 < nir> acl: http: inline:
 390 14:47 < starshine> I agree, but that's not what's beeing discussed on the
 391 Unify* pages that I see here
 392 14:48 < Fabi> starshine, we change our markup only once
 393 14:48 < nir> unify the markup and the code is different
 394 14:48 < nir> we can change the code and keep same markup
 395 14:48 < starshine> true but that's why it needs discussion
 396 14:48 < starshine> in fact has had discussion
 397 14:48 < nir> but the markup is broken anyway
 398 14:48 < starshine> but I think the best parts of the discussion are being
 399 lost here and there..
 400 14:49 < nir> like no [page lable] markup
 401 14:49 < Fabi> ok what about not providing a markup for inclusion?
 402 14:49 < nir> works in the navibar only
 403 14:49 < Fabi> Images are handles as they are now
 404 14:49 < starshine> search on the work Markup finds:
 405 14:49 < Fabi> you can use [[Image.png|Image.png]] to get an link
 406 14:49 < starshine> MarkupProposals, WikiMarkup, RestMarkupSpec <- are these
 407 related?
 408 14:50 < Fabi> may be even [[Image.png|]]
 409 14:50 < starshine> 4 bugs about markup
 410 14:50 < nir> Fabi, what it does?
 411 14:50 < starshine> one of which is the same bug misspelled ;>
 412 14:50 < Fabi> create a link to the Image
 413 14:50 < nir> why the |?
 414 14:51 < Fabi> or any other sererator between link and title text
 415 14:51 < Fabi> I suggest | because it is used in the WP
 416 14:51 < Fabi> and it is intuitive
 417 14:51 < starshine> reStructuredText? ??
 418 14:52 < Fabi> and solves the whitespace problem
 419 14:52 < Fabi> starshine, is an different kind of markup
 420 14:52 < nir> introducing the | problem :)
 421 14:52 < Fabi> which appears much less often
 422 14:52 < nir> yea, its better then whitespace
 423 14:52 < starshine> ok good I can ignore it then :)
 424 14:53 < Fabi> and can be solved by \\quoting
 425 14:53 < starshine> WikiMarkup is just a gloss entry for the term, ok
 426 14:53 < Fabi> or || quoting
 427 14:53 < nir> but | is good only for one argument
 428 14:53 < nir> what if you want to add more data?
 429 14:53 < starshine> it looks like MarkupProposals is the best place to look
 430 at who's been having some of this argument..
 431 14:54 < Fabi> what kind of data?
 432 14:54 < nir> like [[Image.png title:text accesskey:H]]
 433 14:54 < nir> maybe its not the best example
 434 14:55 < Fabi> use several |
 435 14:55 < nir> in that case , is more natural
 436 14:55 < Fabi> we won't use a text: keyword!
 437 14:55 < nir> [[a,b,c]]
 438 14:55 < nir> we already use it
 439 14:55 < Fabi> but , is much more likely part of the text
 440 14:55 < nir> http:
 441 14:56 < Fabi> where do we use , ?
 442 14:56 < nir> "what about quoting"
 443 14:56 < Fabi> has an unneeded char at the beginning
 444 14:56 < nir> [["page name" "this is the label"]]
 445 14:57 < Fabi> 4 letters instead of one
 446 14:57 < Fabi> 5 to be more presice
 447 14:57 < nir> but mayeb we need it anyway in other places
 448 14:57 < Fabi> not if we design our markup well
 449 14:58 < Fabi> we don't even need it in our acls IIRC
 450 14:58 < nir> we don't use it acl
 451 14:59 < Fabi> it's a huge topic
 452 14:59 < nir> we need to see a complete markup to discuss
 453 15:01 < Fabi> using a markup that is more like the WP markup is a good idea
 454 15:01 < Fabi> but there is a lot of stuff that simply does not match
 455 15:01 < starshine> *sigh*
 456 15:02 < Fabi> and that is simply not good
 457 15:03 < starshine> now a *good* point is that the colon has special use for
 458 abbrev's in Finnish
 459 15:03 < starshine> so using colon for special wikimarkup meaning gives them
 460 pains
 461 15:06 < Fabi> wedon't use it for markup but is ahs special meaning
 462 15:07 < starshine> that use'rs point was that interwiki markup looks just
 463 like their standard abbrevs and has to be bang or 6quote killed all the
 464 time, pita.
 465 15:09 < starshine> what we definitely don't want, is to interfere with over
 466 exuberant smileys :))
 467 15:21  * Fabi -> bed
 468 15:21 < Fabi> n8
 469 15:21 < nir> good night