09:23 < nir> with attribtues 09:24 < nir> its like startContent 09:24 < Fabi> I don't know enough about this section thing to come to a desicion 09:24 < nir> but that one has only id 09:24 < nir> #!section simply put rendered markup inside a div 09:25 < nir> then this div can be designed by css 09:25 < nir> for example a floating sidebar 09:25 < nir> or floating image 09:25 < nir> or part of a document with special meaning 09:25 < xorAxAx> i think it is quite harmless 09:26 < xorAxAx> and it doesnt break any api (like other suggestions :)) 09:26 < starshine> like an included page tidbit even, with this in charge of the floatiness? 09:26 < nir> we have to add this to all formatters 09:26 < nir> or at least to the base 09:27 < nir> we need also span 09:27 < nir> currently the only way to create a span with some attribtues is by code_token 09:27 < starshine> could we use this to float code sidebars? I'd think so 09:28 < nir> it will not work for code 09:28 < starshine> awww 09:28 < nir> since you can't nest {{{}}} 09:28 < nir> also code tend to be wide 09:28 < xorAxAx> i suggested a protocol to solve that issue 09:28 < starshine> oh, first }}} would close wrong :/ 09:29 < starshine> but you could use include to do it; code example on other page? 09:29 < nir> include works if you need it 09:29 < nir> also inline: 09:29 < starshine> so that'd be yes, after one level of indirection :) 09:30 < nir> inline is a very good solution when you have code you want people to download anyway 09:30 < starshine> screen's man page says: A weird imagination is most useful to gain full advantage of all the features. 09:41 < starshine> inline shows it with a download link? 09:41 < nir> yea 09:42 < nir> the content, then a download link 09:42 < starshine> cool 13:48 < nir> there is a page about this http://moinmoin.wikiwikiweb.de:80/UnifyParsersAndMacros 13:51 < Fabi> but there are still lots of undesided things 13:51 < Fabi> and problems 13:53 < nir> Fabi, you did not mention that on that page :-) 13:54 < Fabi> most stuff is already on the page 13:55 < nir> the last idea of [[]] for link and {{}} for include can be nice 13:55 < Fabi> changin the markup is always and obiously critical 13:55 < nir> but {{plugin:name}} is little long 13:55 < nir> although not much long then http:// 13:56 < Fabi> it is too long for [[BR]] 13:56 < nir> we don't like BR anyway 13:57 < nir> in most cases its hack to overcome problems in our markup or the css 13:57 < nir> or just misused 13:58 < Fabi> I would use inline: as a keyword and provide a markup for plugins 13:58 < Fabi> this make more sense IMHO 13:59 < nir> so [[link]] [[inline:include]] 13:59 < Fabi> as inline is used much less often 13:59 < Fabi> or stick to the Include macro 13:59 < xorAxAx> ThomasWa1dmann: no 13:59 < xorAxAx> ThomasWa1dmann: feel free to try it :) 14:00 < nir> so what will be the macro markup? 14:00 < Fabi> .oO(some conversation is so slow that it is hard to follow...) 14:00 < nir> and what about macros and parser unification? 14:00 < Fabi> I would suggest using one markup for both 14:00 < Fabi> may be {{PluginName(args) text}} 14:00 < Fabi> and use [[ ]] for links 14:00 < nir> so [[]] will be always links? 14:01 < Fabi> yes 14:01 < Fabi> if we change our markup we should try to move it more to the MediaWiki syntax 14:01 < Fabi> which is not such different (if you ignore the HTML tags) 14:01 < nir> so how do you add an image or attachment? 14:02 < nir> and link to attachment or image? 14:02 < Fabi> images and attachments will go away in 1.4 14:02 < nir> of course they will not 14:02 < Fabi> there will only be URLs and Pages 14:03 < starshine> ha 14:03 < Fabi> the question is if we stick to the autoinclution of images 14:03 < nir> yea, but you still need a way to add either a link or the content of the link 14:03 < starshine> I gave ideas for these to be described. to TW a while back. 14:03 < starshine> and I *like* being able to stash images within my wikispace 14:03 < nir> [[http://example.com/image.png]] should be a link 14:04 < nir> same for [[Page Name]] 14:04 < nir> and if you don't use http://example.com/image.png for the image include 14:04 < Fabi> ok, so we could use [[include:http://example.com/image.png]] 14:04 < nir> you need markup for include 14:04 < nir> no 14:04 < nir> [[]] is a link 14:04 -!- J-PGuerard [tylor@JPG.fan.moinmoin] has joined #moin 14:05 < nir> should never use for include 14:05 < nir> that not consitent 14:05 < starshine> I think display-as-link and display-as-inclusion should be the basis on which related wikimarkup is considered 14:05 < nir> so we need markup for include, or use include macro 14:05 < nir> or inline: 14:06 < nir> but inline: is bad, we must avoid this markup 14:06 < nir> unless we support inline:"name with spaces" 14:06 < starshine> [http://url/is.here/ Name Title] {http://url/is.here/ included-thingy's headline} 14:06 < nir> same for attachments 14:07 < nir> thats the last idea on the unify page 14:07 < Fabi> there are no attachments 14:07 < starshine> I want attachments 14:07 < starshine> I use them a lot 14:07 < Fabi> no you don't 14:08 < nir> there are pages which are files, or attachments 14:08 < starshine> if you take away attachments you'll break my wiki 14:08 < nir> we should use the old names if possible 14:08 < starshine> Fabi: are you trying to tell me how I use my wiki?? 14:08 < Fabi> attachments already ahve page names 14:08 < starshine> I mean, sure, my wiki isn't very big... 14:08 < starshine> but I do use it. 14:08 < nir> starshine, the idea is that attachment will be like a page 14:08 < Fabi> starshine, we are talking about the internal implementation 14:09 < starshine> oh ok. 14:09 < nir> from the wiki pov, attachemnt is just another page 14:09 < nir> from the user view, its a file she uploaed 14:09 < Fabi> and there is no reason to need the attachment: thing 14:09 < nir> and want to include somewhere 14:10 < nir> I think Include(name) can be used for all types of pages 14:10 < starshine> what about pictures? 14:10 < nir> or if we have a markup for include - then {{name}} 14:10 < Fabi> will get pages if uploaded 14:10 < nir> {{/picture.png}} 14:11 < nir> can be a sub page which is a png image 14:11 -!- drewr [~drew@drewr.active.supporter.pdpc] has quit ["home"] 14:11 < nir> or {{FrontPage/Logo.jpg}} 14:11 < Fabi> even without the / if you want to use it wiki wide 14:11 < nir> include a sub page from another page 14:11 < starshine> so I had suggested [[linkthings]] and {{inclusionThings}} with the idea of an extra character for what type 14:11 < starshine> e.g. [[: :]] {{: :}} 14:12 < nir> but you don't need that character 14:12 < Fabi> I like :}} 14:12 < Fabi> it looks funny 14:12 < nir> its too perlish 14:12 < nir> for type we should use clear names 14:12 < nir> like http: 14:12 < nir> mailto: 14:12 < starshine> you only need types for things that act different enough people will want to mark them so 14:13 < Fabi> about what differences are you talking about? 14:13 < nir> but what is different? 14:13 < nir> only macros I think 14:13 < Fabi> .oO(hehe faster) 14:13 < starshine> e.g. inclusion that's just an inclusion (attachment: Include() and possible others), vs. inclusion that also offers download (inline:) 14:13 < nir> Fabi, you are closer to the irc server :) 14:14 < nir> an image page can always offer a download link when you include 14:14 < nir> while a text page will not 14:15 < nir> another option is to have 3 markups 14:15 < nir> [[link]] {{include}} ((macros)) 14:15 < nir> this will make lisp users happy :-) 14:15 < Fabi> ((Macro(args))) 14:15 < starshine> ooh and then you don't need parens around the macro's parameters? 14:15 < starshine> heh 14:15 < nir> ((macro args)) 14:16 < starshine> I'm with nir, less typing's good 14:16 < Fabi> .oO(we need a lisp plugin 14:16 < starshine> lotsa insipid silly parentheses 14:17 < nir> macro is always an include, but it save the extra word needed in {{plugin:include}} 14:17 < nir> or use {{{macro}}} 14:18 < starshine> {{{somemacro\n bla bla bla bla bla yak yak long stuff \n more stuff\n}}} 14:18 < starshine> ^ ? 14:18 < starshine> parser done this way is just a macro with a LOT of parameter, right? 14:19 < nir> one big argument 14:19 < starshine> can a macro tell if it was invoked square or curly style? 14:19 < starshine> maybe macros could have their own methods for being told to be linkish or includes 14:20 < nir> currently its totally different code 14:20 < nir> you want to call a macro in a link? 14:20 < nir> what is the result? 14:20 < starshine> .o( we're scaring people off :) 14:20 < starshine> welllllll depends on the macro I'd think 14:20 < nir> lets say a macro return some html 14:21 < nir> how it can be a link? 14:21 < nir> macro is always an include 14:21 < nir> it can return a link 14:21 < starshine> maybe I have a FindMeAPageWith macro, it might be able to return a hotlink in one case, some sample text of and *then* a hotlink in the inclusive mode 14:21 < nir> but its "include the output of the macro here" 14:22 < nir> but that means you need to have a markup for macro 14:22 < starshine> people will want to define macro by intent :) 14:22 < nir> like [[code:macroname]] 14:22 < nir> and {{code:macroname}} 14:22 < nir> cause [[name]] is a page 14:23 < starshine> ok if something is a URL then "code:" there will look like (surprise) http: 14:23 < nir> pages are the first class in a wiki 14:23 < starshine> or maaaybe https: 14:23 < nir> well thats was my suggestion 14:23 < nir> name is a page 14:23 < nir> macro:name or plugin:name etc. is a plugin 14:23 < starshine> [[macroname:stuf as arguments]] changes soemthing from the http: handler to the whateveritis. 14:24 < nir> but then your have {{plugin:BR}} 14:24 < starshine> [[interwikithingy:pagename]] also seems to happen, right? 14:24 < nir> everything can be represented as url 14:24 < nir> type:data 14:25 < Fabi> just as example: 14:25 < starshine> might reserve [[unrecognizedwidget:bla bla]] for interwiki check, and leave {{unrecognizedwhatsit:bla bla bla}} as macro invocation 14:25 < nir> can be {{run:BR}} 14:25 < Fabi> WP uses [[Image:Name.png]] to include an image 14:25 -!- DuckMaster [~Duck@dyn-83-157-148-56.ppp.tiscali.fr] has joined #moin 14:25 < Fabi> and [[:Image:Name.png]] to make an link to it 14:26 < nir> wikipedia? 14:26 < Fabi> yep 14:26 < nir> quite ugly markup 14:26 < xorAxAx> Fabi: also known as mediawiki 14:26 * Fabi agrees 14:26 < xorAxAx> Fabi: dont confuse the evil guys 14:26 < starshine> I would think... if we were to change anything.... we should make it so that things are easier to "just guess" - not to chase some other wiki type around. 14:27 < Fabi> xorAxAx, I don't know if they really use a regular MediaWiki 14:27 < xorAxAx> Fabi: sure 14:27 < nir> we should change what is currently broken 14:27 < xorAxAx> Fabi: just tweaked with thousands of caches 14:27 < nir> and use most used markup of possible 14:27 < Fabi> ok, images are normally included 14:27 < nir> unless we have really much better one 14:27 < Fabi> most other pages are normally not 14:27 < Fabi> for including pages we can use an Include macro 14:28 < Fabi> for including images we can not 14:28 < nir> if pages and image are the same, we should use same markup 14:28 < nir> I don't see any reason why including a page should be different than an image 14:29 < xorAxAx> ACK 14:29 < Fabi> I just want to sketch the use cases 14:29 < starshine> "better" would be best, if I can do things like describe the reasoning of it across a phone without making people scratch their heads 14:29 < xorAxAx> "we can use an Include macro" doesnt sound like a use case 14:29 < starshine> if I can say "basically any of the square brackets mean..." then I'm ahead on that 14:30 < Fabi> ok what about doing it the other way round as WP 14:30 < Fabi> [[Name.png]] is a link 14:30 < Fabi> [[:Name.png]] is an image 14:30 < starshine> do we have a page to argue about possible wiki markup? 14:30 < Fabi> [[:Name]] is an included page 14:31 < nir> we can use this 14:31 < Fabi> UnifyParsersAndMacros 14:31 < nir> but its the same as [[link]] {{include}} 14:31 < nir> [[: == {{ 14:31 < starshine> Fabi: for other types of mark besides macros though ? 14:31 < Fabi> no because we need the { } for the macros/processors 14:31 < starshine> ok 14:32 < nir> but macros and parsers are includes also 14:32 < Fabi> no 14:32 < starshine> [[ thingies are direct code, really handled by moin, {{ things are addins? 14:32 < Fabi> they are not 14:32 < nir> they include the content of the macro 14:32 < nir> the output 14:33 < starshine> {{themeMyInclusionWeirdly:othertheme\nbla bla bla yak bla\n}} ? 14:33 < Fabi> but they don't point to an external object which you can deside to linkto or include 14:33 < Fabi> plugins are a different name space 14:34 < nir> because you decided that [[]] is point to external object 14:34 < starshine> ok so [[ is generate html and {{ is generate wikistuff to be further parsed? 14:34 < nir> but [[is a link]] 14:34 < nir> so we need 3 types of markup 14:34 < Fabi> yes 14:34 < starshine> [[is a link]] <- a non camel case page name :) people will enjoy that 14:34 < Fabi> link, include and plugin 14:35 < starshine> right, [[ {{ (( 14:35 < starshine> :D 14:35 < Fabi> I don't like (( much 14:35 < xorAxAx> starshine: why? ["it does already exist" 14:35 < xorAxAx> ...] 14:35 < nir> [[is better]] 14:35 < Fabi> ["Sucks"]] 14:35 < xorAxAx> yeah, easier to type 14:35 < nir> looks better, easier to type 14:35 < starshine> [[ same char is very easy to type 14:35 < starshine> " is a shifted char 14:35 < nir> [[[[[[[[[[[[[[[[ 14:36 < xorAxAx> but the difference is not that big 14:36 < xorAxAx> starshine: [ is similar to a shifter char 14:36 < nir> on german keyboard [ is hard no? 14:36 < xorAxAx> starshine: on a german keyboard 14:36 < xorAxAx> it is ALT GR + 8 14:36 < starshine> keyboard may vary, but, I see " always shifted, [ usually not 14:37 < Fabi> ok, is it consensus that we need 3 kinds of markup? 14:37 < nir> I think its the best option 14:37 < nir> just save typing 14:37 * starshine wishes wikipedia had a keyboards of the world page like its flags of the world :) 14:37 < xorAxAx> which 3? 14:37 < nir> and you can see right away what its doing 14:37 < starshine> welll... if he doesn't like (( ... << ? 14:37 < nir> but you have to learn the meaning first 14:38 < nir> 2 markups are easier to learn 14:38 < Fabi> what about [[PageLink|Image.png]]? 14:38 < nir> its better for spaces in names 14:38 < starshine> heh, we could use and it could look like php 14:38 < xorAxAx> Fabi: how do you escape | in the names? 14:38 < xorAxAx> starshine: or <% and let it look like JSP 14:39 < Fabi> my point is not the | 14:39 < starshine> but the same char would still be easy :) 14:39 < xorAxAx> Fabi: what should it do? 14:39 < Fabi> my point are image links 14:39 < xorAxAx> Fabi: alias the link? 14:39 < starshine> ok 14:39 < xorAxAx> Fabi: with a string or a link? * starshine digs out a decent browser for page editing.. 14:39 < nir> soruce|label 14:39 < Fabi> an images that is a link to somewhre else 14:40 < xorAxAx> that is not very intuitive 14:40 < nir> why not 14:40 < xorAxAx> in fact, you even have to remember the order 14:40 < Fabi> but used quite often 14:40 < xorAxAx> what if someone supplies 2 non-images? 14:40 < starshine> Unify... um.. 14:40 < Fabi> the question is how to you see that the label is an image 14:40 < nir> the first is the source 14:40 < xorAxAx> nir: source? 14:40 < xorAxAx> nir: he sketched it differently 14:40 < nir> [[link]] [[link|with text]] 14:40 < Fabi> xorAxAx, link target 14:40 < nir> its very clear 14:41 < xorAxAx> Fabi: target != source 14:41 < starshine> .o( hope I remembr my pw 14:41 < Fabi> href 14:41 < xorAxAx> in fact, they are mutually exclusive 14:42 < starshine> 3 results 14:42 < nir> [:include:]? 14:42 < starshine> Unify Pages And Attachments 14:42 < starshine> Unify Parsers And Macros 14:42 < starshine> Unify Parsers And Processors 14:43 < Fabi> [[Pagename|[[Image.png]]]] 14:43 < Fabi> [[Pagename|[[:Image.png]]]] 14:43 < nir> ho 14:43 < Fabi> [[Pagename|((Image.png))]] 14:43 < nir> why the second [[]]? 14:43 < Fabi> [[[[[[((((((]]]]]]|||||))))) 14:43 < starshine> heh 14:43 < Fabi> because it is an include 14:44 < Fabi> and not plain text 14:44 < nir> [[[[[[[[[[[[[[[[[[[[[[[[[[[[[((((((((((((((((()))))))))))))))]]]]]]]]]]]]]]]]]]]]]]]]]]] 14:44 < starshine> why do you need two of it once you're inside the right delimiter 14:44 < nir> yea, that suck 14:44 < Fabi> [[Pagename|Image.png]] renders a a link with Image.png as text 14:44 < nir> better to use a type: word 14:45 < nir> [[Page|image:logo.jpg]] 14:46 < Fabi> I see no reason why start with keywords at exactly that place 14:46 < nir> because [[Page|[[Image.png]]]] is impossible 14:46 < starshine> ugh 14:46 < Fabi> why 14:46 < Fabi> it's very rare anyway 14:46 < starshine> ok these things seem to be about unifying the under the hood mechanism 14:46 < starshine> and that's good 14:46 < nir> more then one level of those [[ is hard to read 14:46 < starshine> but unifying the markup... 14:47 < Fabi> starshine, our markup is in urgend need to egt unified 14:47 < nir> we already use keywords 14:47 < Fabi> s/d/t/ 14:47 < nir> acl: http: inline: 14:47 < starshine> I agree, but that's not what's beeing discussed on the Unify* pages that I see here 14:48 < Fabi> starshine, we change our markup only once 14:48 < nir> unify the markup and the code is different 14:48 < nir> we can change the code and keep same markup 14:48 < starshine> true but that's why it needs discussion 14:48 < starshine> in fact has had discussion 14:48 < nir> but the markup is broken anyway 14:48 < starshine> but I think the best parts of the discussion are being lost here and there.. 14:49 < nir> like no [page lable] markup 14:49 < Fabi> ok what about not providing a markup for inclusion? 14:49 < nir> works in the navibar only 14:49 < Fabi> Images are handles as they are now 14:49 < starshine> search on the work Markup finds: 14:49 < Fabi> you can use [[Image.png|Image.png]] to get an link 14:49 < starshine> MarkupProposals, WikiMarkup, RestMarkupSpec <- are these related? 14:50 < Fabi> may be even [[Image.png|]] 14:50 < starshine> 4 bugs about markup 14:50 < nir> Fabi, what it does? 14:50 < starshine> one of which is the same bug misspelled ;> 14:50 < Fabi> create a link to the Image 14:50 < nir> why the |? 14:51 < Fabi> or any other sererator between link and title text 14:51 < Fabi> I suggest | because it is used in the WP 14:51 < Fabi> and it is intuitive 14:51 < starshine> reStructuredText? ?? 14:52 < Fabi> and solves the whitespace problem 14:52 < Fabi> starshine, is an different kind of markup 14:52 < nir> introducing the | problem :) 14:52 < Fabi> which appears much less often 14:52 < nir> yea, its better then whitespace 14:52 < starshine> ok good I can ignore it then :) 14:53 < Fabi> and can be solved by \\quoting 14:53 < starshine> WikiMarkup is just a gloss entry for the term, ok 14:53 < Fabi> or || quoting 14:53 < nir> but | is good only for one argument 14:53 < nir> what if you want to add more data? 14:53 < starshine> it looks like MarkupProposals is the best place to look at who's been having some of this argument.. 14:54 < Fabi> what kind of data? 14:54 < nir> like [[Image.png title:text accesskey:H]] 14:54 < nir> maybe its not the best example 14:55 < Fabi> use several | 14:55 < nir> in that case , is more natural 14:55 < Fabi> we won't use a text: keyword! 14:55 < nir> [[a,b,c]] 14:55 < nir> we already use it 14:55 < Fabi> but , is much more likely part of the text 14:55 < nir> http: 14:56 < Fabi> where do we use , ? 14:56 < nir> "what about quoting" 14:56 < Fabi> has an unneeded char at the beginning 14:56 < nir> [["page name" "this is the label"]] 14:57 < Fabi> 4 letters instead of one 14:57 < Fabi> 5 to be more presice 14:57 < nir> but mayeb we need it anyway in other places 14:57 < Fabi> not if we design our markup well 14:58 < Fabi> we don't even need it in our acls IIRC 14:58 < nir> we don't use it acl 14:59 < Fabi> it's a huge topic 14:59 < nir> we need to see a complete markup to discuss 15:01 < Fabi> using a markup that is more like the WP markup is a good idea 15:01 < Fabi> but there is a lot of stuff that simply does not match 15:01 < starshine> *sigh* 15:02 < Fabi> and that is simply not good 15:03 < starshine> now a *good* point is that the colon has special use for abbrev's in Finnish 15:03 < starshine> so using colon for special wikimarkup meaning gives them pains 15:06 < Fabi> wedon't use it for markup but is ahs special meaning 15:07 < starshine> that use'rs point was that interwiki markup looks just like their standard abbrevs and has to be bang or 6quote killed all the time, pita. 15:09 < starshine> what we definitely don't want, is to interfere with over exuberant smileys :)) 15:21 * Fabi -> bed 15:21 < Fabi> n8 15:21 < nir> good night