Topic Agenda: http://www.wikicreole.org/wiki/19JunMeeting [INFO] Channel view for “#creole” opened. welcome everyone hello chuck welcome everyone is anyone else here? -->| MartinJ (i=www-data@bmw.hnvc.net) has joined #creole hi hi MartinJ hi Sheep ;) Hi everybody! hi yves! the agenda can be found at http://www.wikicreole.org/wiki/19JunMeeting Hi all chuck, you will moderate here, right :) yes should I make the channel +m then? :) so, Yves has asked why is whitespace allowed before and after the hyphens in horizonal rules just kidding space after is rather obvsiou -- it's invisible, so we cannot make it meaningful in any way s/obvsiou/obvious from what I remember, we made it that way to give the user more freedom, but i don't really see much of the point anymore ChuckSmith: how does it give more freedom? so, we agree that trailing spaces are ok? yes yes yes otherwise it would be yoo strict yes they should be ok everywhere Space _before_ doesn't have a meaning in creole, since we don't use leading whitespace for pre-formatted. Thus we don't specify it. I agree is the way the spec currently treats it ok? I meant trailing spaces should be ok at the end of any line I don't quite understand could you clarify? Who? but what is wrong with leading whitespaces? under horizontal rule, Yves wrote: "Note: why are leading spaces permitted here? YvesPiguet" Christoph: if awiki uses mixed mode, and uses leading whitespace for
, then we have trouble
		RadomirDopieralski: Well, in mixed mode, we have to assume that people know about priorities.
		RadomirDopieralski: In this case, the local formatting rule of leading whitespace = pre takes precedence.
		We must assume that mixed mode wikis will run into more of these issues.
		AlexSchroeder: makes sense
		And I claim we cannot make Creole collision free.
		Therefore, let us just accept it.
		does everyone agree that I can just remove Yves' question about leading spaces from the spec?
		wait, I have one more question
		So do you mean that we should accept leading spaces in front of any line?
		what do the leading spaces give us?
		I mean, what is the advantage?
		I think, there is no need for leading spaces, users benefit is not that big, and they are not allowed before headings
		Newbie tolerance for wikis that don't have conflicting local markup rules.
		They are allowed for bullet points.
		People will put leading whitespaces in front of it to "Visually" indent.
		So you could argue that they should be allowed before headers.
		yes, and still be rendered as a header, right?
		headings and lists are indented by the number of = * or #
		Christoph: You mean, of the set (bullets, headings, horizontal line) only bullets will be indented by newbies?
		I've seen '----' centered (with spaces) when used in place of asterism
		something like this, yes
		the way the JSPWiki Creole filter handles it currently is actually wrong
		I guess that was your complaint yves, right?
		so, should we also allow leading spaces for headers?
		yes
		?
		Christoph: no, I wondered why there was a difference between different markup
		it would be nice for it to be uniform
		ok
		True.
		I agree
		if we allow leading spaces before headings, does that make it more consistent?
		no, don't allow any leading spaces, I think ueser can accept that ?!
		If we go that way, we should allow them before arrays too
		Thats also how most wiki engines handle it
		arrays?!
		tables, sorry
		ugh
		Well, he has a point.
		yeah
		An Ugh point.
		do we really want leading spaces before tables?
		then again, allowing spaces disables one obvious form of 'escaping'
		I'd actually prefer no leading space anywhere...
		me too
		So what was the reason for allowing whitespace in front of list items? A source of mistakes? Doesn't that carry over to all other markup?
		well, I know, for one, that TracWiki requires whitespace in front of a bullet point
		AlexSchroeder: the reason was that some engines use indetation for lists, and also some users will additionally indent them to improve presentation
		I don't mind either way, but I do think that we should try and be consistent, or explain why bullet items need an exception from the rule.
		don't know if any other engines do this
		AlexSchroeder: it doesn't carry to other markup, as only lists have hierarchy
		RadomirDopieralski: That's true, but those users will be disappointed anyway, since the indentation is lost.
		AlexSchroeder: I think the idea was "forgiving" markup
		Christoph: Well, "forgiving" would extend to other markup rules as well.
		AlexSchroeder: the idea is to minimize the amount of work required when copy-pasting text from other sources
		RadomirDopieralski: "Minimize work" would also extend to other markup rules.
		AlexSchroeder: adding some *'s is less work than removing all indentation
		yes
		AlexSchroeder: but headings are rarely indented?
		RadomirDopieralski: Are you at the same time claiming that this kind of copy-paste situation doesn't occur for tables and horizontal lines?
		AlexSchroeder: it does occur for tables, agreed
		AlexSchroeder: hosrizontal lines don't come in batchs
		well, if we allow spaces before markup that is then still interpreted, then we will have to have it for all markup, right
		(bacthes?)
		I think the test is to save an HTML page containing headers & tables as plain text and see whether Firefox indents all of the text or only list items.
		ok, I just modified the spec so whitespace is allowed before opening equals in headers
		That would answer the question about relative numbers.
		Perhaps this problem is confined to list items only.
		ChuckSmith: It seems to me that the issue remains unsolved.
		well, it's a wiki, so we can change it back...
		Let me quickly install my edit-bot... ;)
	* RadomirDopieralski	installs a revert bot
		I'm just saying... You're taking the wind out of my effort to develop a line of reasoning that will explain whatever decision we'll reach eventually.
	* ChuckSmith	edits Radomir's revert bot
	-->|	m_tenc_ (n=mario@i577B50A7.versanet.de) has joined #creole
		ChuckSmith: What's your proposal for the rest of the rules, then?
		hi m_tenc_
		Will you change those as well?
		I think only headings need leading whitespace... but I can't think of good reasoning to back myself up other than intuition
		headings, lists, horizontal rule
		the general rule from the very beginning as I remember was: whitespaces in front of markup should not have a meaning -> thus: it is allowed, markup will still be rendered
		I think that there is an important difference between lists and headings/lines: rarity. Wiki markup is designed to make the most often used elements easy to get, and the rarer ones not conflict.
		I understand Christoph's line of reasoning.
		so then should we allow leading whitespace in front of table lines?
		I don't understand RadomirDopieralski's line of reasoning, because "rarity" implies a way of counting. Are we talking "mistakes made on Wikipedia" or "mistakes introduced by using copy & paste from Word" or something else entirely?
		It was this thing that we did not wanted what mediawiki does: escaping by the means of leading whitespace:
		we did not?
		In any case, the claim of "rarity" needs at least one example of where I can develop an intuition of the question.
		whether leading spaces allowed or not, there should be a general behavior, without exceptions
		relative rarity of lists vs. headings is a matter of style
		I think this would be usability
		I agree with Martin
		I agree
		MartinJ: ok, since we really need to allow whitespace in front of lists, the "no exceptions" rule pretty much forces us into one approach
		And usability would be: Allow whitespaces?
		when I saved the Creole 1.0 spec as a txt file in Firefox on Mac, it does not add leading whitespace in front of the table
		YvesPiguet: But we must be thinking of relative rarity with respect to something that matters, eg. mistakes made. Because if nobody makes mistakes, then there's no way to decide whether something is easy or hard.
		ChuckSmith: But it does add whitespace to list items, right?
		yes, it does add whitespace to list items
		Kensanata: if there is the same rule for everything, relative rarity doesn't matter
		Christoph: I think so usability would be to allow spaces, even if it is a very small benefit for the user (IMHO) and even I don't like leading spaces...
		I agree
		Ok. So if we determine this to be "a source of errors", and our reasoning is that we want to minimize those, then we can have the general rule of not allowing whitespace, with the exception of whitespace before bullet lists. Because of the "save as text" example.
		That would be the kind of reasoning I understand.
		sounds good
		http://www.wikicreole.org/wiki/Sandbox
		Specially since "save as text" doesn't really produce anything usable for headings and tables, as far as I remember. Perhaps ChuckSmith can shed some light on it.
		so, if I understand, we want to allow leading spaces only before list items and not before horizontal rules, headings and tables?
		ChuckSmith: Exactly, because "save as text" (and perhaps "copy from word") will only add it there.
		when it saved the table, it just saved it with spaces
		Chuck: no
		And the reasoning is we want to have simple rules, but we will add an exception to minimize errors.
		But that's just one browser... Do we really want to use it as the final authority?
		YvesPiguet: Not really. But at least n=1 in this case. Before this example, we just had "intuition". :)
		Kensanata: it would be simpler to permit spaces everywhere
		we could just allow leading spaces before everything and be done with it :)
		So I'd be _very happy_ if somebody did the "copy from word" example.
		YvesPiguet: I agree
		I don't have Word on this computer
		Me neither.
		damn Mac users ;)
		d:)
		Just to provide you with a cautionary example:
		5
		+ 2
		= 7
	|<--	MartinJ has left irc.freenode.net ("CGI:IRC (EOF)")
		will render 7 as a heading, right?
		yes
		5
		+ 2
		~=7
	-->|	MartinJ (i=www-data@bmw.hnvc.net) has joined #creole
		so, if no one objects I'm going to add that tables can have leading space in front of them
		Or 5 + 2
		7
		There is one last block element: block preformatted
		add something that every element can have leading spaces...
		http://atos.wmid.amu.edu.pl/~sheep/creoletest.html http://atos.wmid.amu.edu.pl/~sheep/creoletest-firefox.txt http://atos.wmid.amu.edu.pl/~sheep/creoletest-opera.txt
		do we allow spaces before triple-braces?
		I'd say no
		YvesPiguet: that would make it impossible to have 'inline' nowiki alone on a line
		(for symmetry with end mark)
		because then the escaping rules within nowiki would not work anymore :)
		Christoph: ok, lets scrap what we got so far and start over
		RadomirDopieralski: yes, because block preformatted don't have anything else (but spaces) on the same line
		a line can begin with inline nowiki without leading spaces
	|<--	MartinJ has left irc.freenode.net (Client Quit)
	-->|	MartinJ (i=www-data@bmw.hnvc.net) has joined #creole
		just edited the spec to allow leading spaces in front of all elements (perhaps I should add except nowiki blocks)
		YvesPiguet: ah, right, sorry
	|<--	m_tenc has left irc.freenode.net (Read error: 110 (Connection timed out))
		YvesPiguet, ok, than lets keep that as an exception
		ok
		can we go to the next point on the agenda?
		yes
		I'd like to have block plugins similar to block nowiki, but I guess it won't be possible to reach a consensus on that
		multiline list items
		(didn't want to stop the progress of the meeting)
	|<--	m_tenc_ has left irc.freenode.net (Read error: 110 (Connection timed out))
		yeah, I think that's too advanced for core Creole
		multiline list items: * line one \\ line two
		I'm afraid that multiline list items will potentially break wikis who plan to add Creole in mixed mode
		yes
		how so?
		the problem is there is no turning back...
		if wikis currently have a list and then follow it with a paragraph
		I wonder if anyone does that
		without putting a line in between
		Usemod users would do it.
		AlexSchroeder: why?
		Christoph: I'm affraid here is a misunderstanding. What I mean with "multiline list items" is to permit the author to insert a linefeed in the middle of a list item without ending the list and beginning a new paragraph
		RadomirDopieralski: Huh? Because it worked.
		Yves: no, yes that is what I undersand
		* foo
		* bar
		yadda yadda
		The "yadda yadda" would be a separate paragraph, not part of the second list item.
		would yadda yadda be on the same line or under it in the same bullet point?
		Introducing creole on this wiki will be tricky, if creole supports multiline list items.
		Kensanata: but MoinMoin, PodWiki, TracWiki, and WikiModel would do it!
		AlexSchroeder: and what is the resoaning behind it?
		AlexSchroeder: yes thats how most wikis handle it
		RadomirDopieralski: Does it matter what the designers of the old wikis with the lousy markup thought?
		See http://www.wikicreole.org/wiki/MultilineListItems
		Sheep: the reason is wiki legacy?
		the same reason we're using asterisks for bullet points instead of hyphens? :)
		Usemod users can write a backslash before the linefeed to escape it, and Creole can't
		the same reason we have don't handle linebreaks as linebreaks :)
		remind me, why we aren;t using ”italic” and ”'bold”'?
		usemod did
		even wikipedia does
		we have a ””'good””' reason for it
		RadomirDopieralski: The reason is that we expect that adding **bold** doesn't break any existing markup.
		RadomirDopieralski: But adding multiline list items would certainly break existing markup.
		RadomirDopieralski: That's the difference between the two examples.
		yes
		but whatever decision we take, it will break some engines. So we'd better choose one which is consistent with multiline paragraphs
		is anyone besides Yves for Multiline List Items?
		AlexSchroeder: adding **bold** will break any text that has ** in it
	* RadomirDopieralski	is for muliline list items
		I like multiline list items, of course. I support them in Oddmuse.
		I'm just not sure that we need them in Creole.
		Please have a look at http://www.wikicreole.org/wiki/MultilineListItems and see that very few engines would be like Creole
		could we leave that unspecified or does that open another can of worms?
		Yves, I certainly would love multiline list items, but maybe for Creole 1.1?
		i.e. Creole portability
		I think that all the long and windogn discussions about blog-like/wiki-like line ends apply to multiline list items too
		true
		hat's like the escape character, I think it should be in the core because it will be very painful to change
		what do you mean Radomir?
		Christoph: what happens with list items wehn you use blog-like line ends?
		:)
		They kill puppies?
		It does seem to make sense.
		then we'll need a puppy herder...
		blog like linebreaks and multiline list items would certainly be on my list for the perfect markup
		;)
		Argh.
		wiki linebreaks and multiline list items for the win!
		But for Creole?
		ok, lets leave it
		for Creole too
		we are over it, creole will not be perfect
		I don't think it's so crucial
		I agree
		I don't
		We could do a vote. Answer multiline, single line, or undecided...
		I'm undecided
		undecided
		undecided
		undecided
		with which engine do you want to make Creole compatible in http://www.wikicreole.org/wiki/MultilineListItems
		multiline
		Hehehe.
		I guess we go for the win! ;)
		btw, is someone logging this?
		I have logs.
		I'm copying the chat periodically, yeah
		ok, next topic? :)
		lol :D
		promoting Creole
		It seems to me that many are undecided, but nobody feels like arguing against YvesPiguet, and therefore we should try multiline list items.
		I'd say: definitely yes :)
		so, we decided that we're undecided?
		no, wait
		lags
		AlexSchroeder: by 'undecided' you meant 'no vote' or 'leave it unspecified in Creole'?
		I really don't like us reaching such a critical "undecision" in a chat without the usual process.
		Christoph: should we make a poll on the wiki?
		RadomirDopieralski: When I said "undecided" I thought: I'll support either decision.
		AlexSchroeder: ah, I thought 'unpecified' :)
		If you were undecided and therefore prefered single lines, you should have said "single lines".
		unspecified would have the advantage of working as everyone wants, but the disadvantage of some small errors in wiki migration
		Did anybody else misunderstand what "undecided" means?
		RadomirDopieralski: will this poll yield any results other then undecided?
		after some thought, I'd vote AlexSchroeder's 'undecided' too
		so, we only have one meningful vote?
		ok, not a problem for me :)
		shall we allow implementers to decide and to recommend the multliine list items?
		but not require it?
		No seriously, let's add this point "multiline list items" to the creole 1.0 poll and see how it evolves
		then would you agree that we can move the Creole 1.0 acceptance back two weeks to give us time to reflect?
		chuck: yes
		ok
		but I'd prefer that all opinions be argumented
		I hate procrastinating 1.0, but I'd rather do that than have something horrible that's frozen for two yeras
		not just no or yes, but why
		because I think it will be easier to refute arguments for single line that arguments for multiline
		I'm also considering making the current 1.0 as 0.8 and leaving just multiline list items up for discussion for 1.0
		YvesPiguet: you don't need a 'valid argument' to vote :/
		yes, but votes are antiwiki
		no, lets keep the 1.0 label
		ok
		YvesPiguet: how about the 'concensus poll'?
		yes, but to reach a consensus, you have to convince other people, and without arguments it's difficult
		oh, i love that '12 Angry Men' movie :)
		For me: It will take time to see if it makes sense to have multiline list items (like it would take time to see if it makes sense to have blogline linebreaks)
		ok, I added the poll question
		but we already decided about blogline linebreaks, so it should be easier now
		and signed Yves name :) http://www.wikicreole.org/wiki/Creole1.0Poll
	-->|	m_tenc (n=mario@i577B545C.versanet.de) has joined #creole
		so do we postpone 1.0 now because of multiline list items?
		I've added a link to http://www.wikicreole.org/wiki/MultilineListItems
		good
		yes
		I would say the proposal was not treated seriously enough when it was initially brought up
		I think we should discuss URL escaping rules now, and come back to promoting Creole at another meeting
		(since we're not launching Creole 1.0 tomorrow anyway)
		ok
		does everyone agree that we postpone Creole 1.0 for yet another 2 weeks?
		by the way, the wikis from the student experiment are opened for reading for the public now: http://ppr.wmid.amu.edu.pl/a and b
		Christoph: yes
		Christoph: yes
		so, what was the issue of URL escaping rules? I believe Christoph added it to the agenda?
		the idea was to simplify the rules by replacing with this:
		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.)
		sounds good to me... any disadvantages of this?
		sounds good to me too
		If no one opposes, Yves, could you modify the spec as you think it should read?
		how it disables them?
		like this? ~http://this.is.not.a.link
		it disables by showing the link as plain text instead of as a link, right?
		Christoph: I mean how you use it
		argh
		ChuckSmith: ...
		:)
		yes. If a tilde is written in front of anything, this anything isn't autoconverted (to a link, smiley, etc.)
		Chuck: yes
		~:-)
		so no irokez smilies?
		Exactly.
		how about ~~~signatures ?
		Another example of a local conflicting rule that takes precedence.
		ou can always add a counterexception in your engine
		add an exception of the rule
		--~~~~ is this one exception
		I'm still worried about http://epfarms.org/~alex/
		URL, then no escape
		yeah
		and {{{use ~ to escape}}} ?
		space, hence no escape
		and {{{use ~}}} to end the monospace}}} ?
		forbidden!
		unfortunately,i like it ;)
		one more thing to precise: this is a normal link http://foo.bar/~baz
		write it {{{use }}}}}}{{{ to end the monospace}}}
		But wasn't that one of the major uses for an escape character?
		I really don't see why someone would need a ending curly triple brace inline
		Christoph: you can add it to JSPwiki as an exception ;)
		YvesPiguet: Ugh! :)
		ChuckSmith: To explain the rules?
		in block nowiki, you escape the ending triple curly braces by adding a space in front of them
		AlexSchroeder: you can just write {{{somthing}}}}}
		since you can only close a nowiki with no leading spaces
		ChuckSmith: Ah, there's my misunderstanding. I thought that the ~ would _replace_ the existing weird escape sequence we had.
		or better: ##use ~}}} to end the monospace## (but of course, then it would be ## for monospace!)
		no, a tilde would only replace one character
		~=~=~= these are three equal signs
		I'm thinking: Now we get _two_ escape characters! Is this correct?
		???
		not really
		Well, yes
		because the opening nowiki and closing nowiki must have no leading spaces
		outside we have tilde, inside nowike we have whitespace
		so, if you add a leading space, it doesn't count
		in block nowiki, you mean?
		yes
		Christoph: you are wrong, we don't treat whitespace specially in nowiki
		ChuckSmith: That's what I'm saying. Under certain strange circumstances, you can no longer apply your knowledge: "~ is the escape character". You need to know an additional escape character: "Use a space!"
		Christoph: only in preformatted text
		the only rule for nowiki is that the end tag must not have leding spaces
		I mean, this is such a rare case that we spend hours mulling over
		true
		when you need a closing triple curly brace to be in a nowiki block
		it's just because WE need it
		to describe the spec in Creole
		that's another silliness that the escape character introduces
		But wouldn't it be nicer to use ~}}} ?
		because it is just slapped on top of Creole, which was developed without it initially
		Yes!
		here we go again...
		nothing silly here. There are no escape characters in nowiki, that's simple
		AlexSchroeder: how would you write ~}}} then inside nowiki?
		but it would read much easier with the tilde
		~~}}}
		I didn't want to discuss again whether we needed an escape character, or where we needed it, just a slight simplification of the current rules of Creole 1.0
		you would write ~}}}
		because tildes aren't escaped inside nowiki
		Christoph: and how would you write just a tile inside nowiki?
		tilde
		~
		Christoph: and what would '~~' inside nowiki produce?
		because only ~}}} has a meaning
		inside nowiki
		RadomirDopieralski: two tildes.
		ah, a special case
		it's not needed
		yes it is a special case
		and how is this exactly different from the spcae special case?
		but it is easier to read
		RadomirDopieralski: Yes, a special case, just like the other special case. Except that this new special case uses an escape character know from other rules, instead of a whitespace.
		Yes!
		It's a small benefit, I agree.
		the idea was that no escape characters are allowed in nowiki, period
		ChuckSmith: But this space in front of }}} _is_ a weird ugly byzantine escape character!
		AlexSchroeder: it uses an escape character that is being introduced togethr with taht rule and that didn't even exist before eitheri n creole or any other wiki engine except for jspwiki
		I agree with Chuck, and the rules are very simple
		a nowiki block must begin with three curly braces at the beginning of a line
		a nowiki block must end with three curly braces at the beginning of a line
		but at least in JSPWiki
		AlexSchroeder: there is no special treatment of space before }}} in nowiki
		thus, if you want to display an ending curly brace, just put a space in front of it
		RadomirDopieralski: I think there is. It's eaten, no?
		AlexSchroeder: no
		AlexSchroeder: not in nowiki
		AlexSchroeder: only in preformatted
		nowiki = preformatte
		d
		in block
		AlexSchroeder: the technique is called 'space stuffing' and it was used previously in at least one RFC
		Well, let me replay all my arguments and replace nowiki with preformatted.
		yadda yadda yadd
		see?
		AlexSchroeder: how would the ~ work then for inline nowiki?
		actually, could we just let them both work?
		although that does seem a bit silly considering how rare this case is
		ChuckSmith: the point is that treating ~ specially inside preformatted breaks things
		why dont we give it a little more time to discuss?
		Hm.
		this is such an edge case
		it doesn't merit our lack of sleep ;)
		I didn't intend to launch such a discussion
		Perhaps not. I'd rather step back and accept a byzantine rule on this issue instead of repeating this discussion again.
		What's wrong with the current 1.0?
		only minor stuff
		having a poll about whether to use ~}}} to escape the ending nowiki or to use a space seems rather absurd to me
		2 more weeks, but that should definitely be it!
		so you agree that we keep the old greedy inline nowiki and the leading space in preformatted blocks?
		ChuckSmith: I think we had it anyways already
		I do.
		anybody disagree?
		so, we're agreeing to keep Creole 1.0 as it is in relation to nowiki ?
		whatever
		yes
		yes
		Christoph: It's called "undecided" ;)
		so, is that everything for tonight?
		now can we decide on my initial proposition?
		it doesn't change anything wrt greedyness and leading spaces
		we totally skipped the 'creole promotion'
		and I think it's more important
		the greedy inline nowiki: what is if '}}}' follows somewhere else in the paragraph after the already closed nowiki inline?
		<-- preparing a late night dinner.
		}}} outside nowiki is rendered as is
		MartinJ: it only eats the trailing }'s
		and we don't want to look forward
		ok
		MartinJ: so that {{{foo}}}} is rendered as foo} not foo}
		yes, and {{{foo}}}bar}}} is rendered foobar}}}
		ok, I thought it would be greedy at all ;)
		ok, what about promotion?
		The logo contest...
		does anyone of you know people who can design logos?
		can we cover promotion in another meeting?
		I did some commercial designs some time ago
		ChuckSmith: probably good idea
		Chuck, ok
		ChuckSmith: it deserves attention
		yes
		yes
		perhaps we could meet same day next week, but two hours earlier?
		fine by me
		fine by me
		it will be more difficult for people in Tokyo...
		sorry to keep you all up so late
		who here is from Tokyo?
		Mark said he wanted to attend
		are you all from Europe?
		Mark is in #wiki
		wonder if he's active
		or if he just forgot we were meeting...
		I think we are all in Europe
		ok, let's go to bed then ;)
		mmh ok, I still have to work at this time
		tomorrow morning I'll go over the chat log and post it as a txt file attachment to the meeting page
		MartinJ: that's slave driving!
		thank you all for attending!
		Ok, thanks everyone!
		RadomirDopieralski: I don't remember, are you in centreal Europe sumer time?
		and get a good night sleep.... don't have nightmares about The Night of the Living Hyphens
		(yes, I stole Radomir's joke)
		good night!