(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-48) was last changed on 26-Sep-2007 09:06 by ChuckSmith  

This page was created on 21-Mar-2007 16:54 by YvesPiguet

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 117 added 106 lines
1. I maintain my criticism of the definition about the scope where tilde is supposed to escape.
a) the limitation seems artificial, since tilde is not more frequent than many other "reserved" character combinations - most notably the leading hyphen, leading equal signs, or the double backslash (which - being a Microsoft path-escape - will occur in many discussions on Microsoft Office). (NB: I consider the exceptions to double-forward slash similarly artificial, but much more harmless)
b) the rules are so complex that it would be severaly tax my programming power to properly convert existing Wiki content to a new wiki that uses Creole. I realise that this is a personal limitation, but I still consider it possible that others will feel similar...
c) the tilde will most likely be re-used by Wikis using mixed Creole-plus-native markup. This makes the complex scope rules even more complex, and in Wikis that support CamelCase links, the rule would include all tilde+alphabetical character - making a scoping rule essentially worthless.
I propose the tilde to be reserved as escape character, requiring all tilde in the content to be escaped through double-tilde. Without this, content migration from mixed mode Creole-Wiki A to Creole-Wiki B will become a nightmare (trying to figure out which tilde in the content used to be escaping, and which is content...)
If we have serious objections, I propose to use double tilde as escape marker.
2. I have quite a bit of reservation why we do not require a blank after the OL/UL hyphen or number sign (as proposed in Radomir's arguments at the start of [[Talk.HyphenListMarkupProposal]], and in [[RequireSpaceAfterBulletProposal]] - albeit focussing on asterisks). Sorry to bring this up again, but I took the pain to read through [[Talk.RequireSpaceAfterBulletProposal]], and 95% of te discussion has focussed on technical issues on parsers, programning, and ambiguity issues like bullets versus bold. The discussion I would like to see is about making it simple and intuitive and readability for users - which was a major argument in the original proposal. I personally find bullet-plus-blank much more intuitive and readable markup sequence. It would make the Creole specs simpler, not requiring us to explain two alternative ways of list markup!
The one argument that is relevant here is that Chuck made a wikipedia study resulting in 50/50 chance of either markup. I wonder whether this decisive enough, or is due to wikipedia-experts. I challenge everybody to take a look yourself, using the random article function and going into edit mode - which style is more visible and readable? And look at your own emails - which style is being used there?
To me giving both options is two different rules, perhaps because unlike most whitespace rules in Creole and in fact all Wikis I know, this **does not**, correspond to html/xml whitespace normalization. (I consider this an argument for being "intuitive" to a lot of readers, not a technical argument). The difference between "- X" and "-X", or "# X" and "#X" seems to be intuitively significant. Do we really have to support both alternative markup styles?
-- [[Gregor Hagedorn]], 2007-04-04
My position in regard to escape character and hyphen lists is still the same:
* I don't feel convinced we need an universal escape character at all -- maybe we do maybe we don't, we should state the problem we are trying to solve with it and look at various solutions, //including// but not limited to the escape character. Introducing this markup solely for the purpose of making other proposed markup acceptable does fire some warning signals -- maybe if it was proposed in a different situation, the reaction would be different.
Escaping rules, if used, should be made as braindead simple as possible at all. Making them "intuitive" just doesn't work -- every user has different intuition.
* Implementing the escape character in the way proposed in 0.6 is not possible with the approach used in the MoinMoin plugin currently -- so I would have to basically rewrite it from scratch. While I'm pretty much sure that the quality of code would rise tremendously in the process, I don't think I would have enough free time (in large chunks) to actually do it in near future. This is not a threat of any kind or a reason for me arguing against it -- it's just a fact. Of course, if the escape character is really that superior, we should by all means do it. Code is cheap, relatively.
* I **love** the signle hyphens for lists, especially after watching the results of user activity both on the Sylabus wiki and on the wikis prepared for [[TheStudentExperiment]]. However, the multiple-hyphens-for-nested-lists markup is totally unacceptable to me -- it's new and confusing. One solution would be to choose different markup for nesting, another -- forbid nesting altogether, or even propose a different markup for nested lists in the additions. Of course asterisks are nice too and changing the conflict with bold seems like too little a reason for changing the markup entirely.
* I would be glad to see whitespace required after bullets no matter what we use for the lists. But I argued this point enough, and will not come back to it unless there is any new material to consider.
* Lets beware of complicating Creole incrementally as our code base grows -- we want more programmers to jump in, and we want to **ease** their job and remove barriers. How many **active** programmers does Creole have now, how many of them wait for the target to stop moving or even have given up completely already? Do you remember how Creole started and how good it was initially? Lets not spoil that.
By the way, Gregor, it was me who conducted the experiment with counting markup uses on Wikipedia. I admit that it wasn't well-thought -- I just wanted to see what happens, I didn't follow a systematic scientific method. Anybody can repeat this or do some new experiments easily -- the page database of Wikipedia is available for download (unfortunatelly, without the history). But it is very hard to form a consistent, provable theory, you know.
By the way, we agreed to propose these features in 0.6 to see if it's just me who's making a lot of noise, or are there more people. I really made a forest fire and made it really hard to judge -- I can't control my trollish behavior easily and I'm really sorry for that.
-- [[Radomir Dopieralski]], 2007-Apr-08
My opinion on these topics:
* The escape character is an alternative to nowiki (inline triple-braces), much less verbose in some cases. Offering the choice is similar to backslash/verbatim in LaTeX, or backslash/single quotes in shell. Escaping braces with triple-braces quickly becomes painful. I strongly agree that the escape character should be simple. What's currenly in 0.6 is much much worse than no escape character, imo. It isn't a matter of implementation, but of usage, documentation, compatibility with mixed-mode engines, and evolution.
* I don't dislike hyphens, but since nested lists will be supported by at least some engines, the syntax should extend nicely. Idem for mixed numbered/unnumbered lists. I don't like leading spaces for denoting the nesting level, because of the difficulty to count spaces and to distinguish them from tabs. I don't like at all the idea of having both hyphens and stars for unnumbered lists: it's confusing and it eats up one more character available for markup. So I'd prefer to stick with stars, followed or not by a space.
* I'm puzzled by the so-called stable version 0.6.
-- [[YvesPiguet]], 2007-Apr-08
''I'm puzzled by the so-called stable version 0.6.''
If we don't have a consensus about 0.6 we should not tag it as stable and move on to the next iteration. This would be a waste of version numbers. What would you like to see to go into 0.6? I know that you have written a lot about it already, just a summary would be good. We need to come to a decision in order to move onward. My only wish is to see the [[Hyphen List Markup Proposal]] to go into creole so that we can get out our parser modifications and a new version of WikiWizard which will support creole. I need to start using creole in production. Escaping isn't really important here, but how lists are created is important. I don't want to change all the asterisks later into hyphens, you know. As far as I can tell from your last post we at least could agree on this change?
I got a very tight schedule this week, sorry. I will write more as soon as I have time.
-- [[ChristophSauer]], 2007-Apr-10
I'm also going to need to release software based on Creole soon, so I share your concerns.
I know that votes aren't the preferred way to make decisions, but I suggest the following polls.
I propose that everyone caring about these features adds a row with his/her name, and for
each feature a number from 1 (strongly disagree) to 5 (strongly agree), 3 meaning //don't care//.
We can continue to add signed comments below.
I'll wait until this afternoon before starting, in case there is opposition or modification
requests to the poll itself.
//Poll proposition moved to [[Creole0.6PollArchive]].//
-- [[YvesPiguet]], 2007-Apr-10
Do we poll here or better on a separate page, like for example [[Creole0.6PollArchive]]? Btw, I'd replace the spaces with \s in the above regexps, both for including tabs and btter readability.
-- [[Radomir Dopieralski]], 2007-Apr-10
It might be better to have a separate page. For regexps, as long as we keep textual descriptions for people like myself who aren't as familiar with perl or sed as experts like you, no problem! Just clarify how leading spaces and tabs are counted for nesting: sum of tabs and spaces, I'd say.
-- [[YvesPiguet]], 2007-Apr-10
Proposition moved to [[Creole0.6PollArchive]]. Proposed starting time: 6 p.m. CET. Please comment on suggested end on [[Talk.Creole 0.6 Poll]].
-- [[YvesPiguet]], 2007-Apr-10
At first glance, I don't like the tilde too much, either. Is there somewhere where I can read up on its benefits? To me, it feels like a construct that seems nice in theory, but leads to chaos in practice. It would nice to have some motivating examples. It would be useful for escaping free-standing CamelCase words; but that is something I strongly oppose, anyway.
EDIT: I've found the [[EscapeCharacterProposal]].
As for nowiki, do we have a list of duties that this construct must/should fulfill? For example:
* Escaping: Escape any kind of Creole command.
* Monospace font style: Really necessary for writing about code on a wiki page. Do we really want to (ab)use nowiki for this? Or are there other proposals? Is double-sharp a proposed markup for monospace?
* Plain <pre>: This is quite different from the above, mainly in the way whitespace is handled.
* Monospace <pre>: Could be a combination of plain <pre> plus monospace markup.
-- [[Axel Rauschmayer]], 2007-04-11
The last bit is confusing to me - I believe pre-markup (where whitespace is preserved) without monospace does not make sense, all html style I know renderes pre with markup.
I can do without any other form of monospace, especially monospace + bold/italic, thus having block level three-braces for pre and inline-three-braces for nowiki-monospace, as present in this JSPWiki anyways, is fine with me. I can not do very well without escaping creole and native wiki-commands //without affecting formatting//, i.e. even inside a italic or bold-formatted string. There are too many commonly used character combinations part of markup (especially double forward/backward slash. Others here seemed to have claimed the opposite, probably because their use case is computer code.
I prefer Wiki markup to be easily remembered and convenient, therefore I proposed three-braces for block/inline pre/nowiki-monospace, double braces for nowiki (=inline escaping), and tilde for single-character nowiki. The main use case is a requirement to allow one form of escaping that works without affecting sourrounding formatting, however.
-- [[Gregor Hagedorn]], 2007-04-04
Concerning nowiki/pre, this sounds exactly right. I'm still not convinced, we need single-character nowiki.
Another thought: Should there be a construct that allows the insertion of raw HTML?
-- [[Axel Rauschmayer]], 2007-04-11
Then all users would have to learn html to be ble to edit the html others inserted. Also, this would pose considerable implementation problems, especially for the parsers that use somethng different than html for output (a Crele2Latex converter is on the way), not to mention filtering the html to avoid cross-site scripting attacks.
While collecting data for the NowikiMarkupComparison, I noticed that some wiki engines make another distinction: a pre block with spaces and newlines preserved, but wiki markup (like links and emphasis) allowed. My own personal wiki uses a custom markup for pre blocks with proportional fonts -- for the sole purpose of displaying poetry (inserting {{{\\}}} everywhere is hardly convenient, but poems and lysrics set with monospace font are very ugly). Wonder if we should consider these two too? Block-level double-brace anyone? ;)
-- [[Radomir Dopieralski]], 2007-Apr-11
Version Date Modified Size Author Changes ... Change note
48 26-Sep-2007 09:06 21.219 kB ChuckSmith to previous restore
47 26-Sep-2007 00:58 21.622 kB 219.138.204.162 to previous | to last
46 26-Sep-2007 00:57 21.612 kB 161.200.255.162 to previous | to last
45 12-Apr-2007 15:03 21.6 kB 84.150.58.37 to previous | to last
44 12-Apr-2007 09:01 21.42 kB 80.92.102.210 to previous | to last
43 11-Apr-2007 23:48 21.219 kB RadomirDopieralski to previous | to last everyone would need to learn html; more pre variants
42 11-Apr-2007 21:51 20.311 kB 84.150.2.66 to previous | to last
41 11-Apr-2007 21:42 20.224 kB 84.150.2.66 to previous | to last
« This page (revision-48) was last changed on 26-Sep-2007 09:06 by ChuckSmith