| At line 1 added 11 lines |
| == 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]]. |
|
| ------------ |
|
| At line 229 added one line |
| Hi Radomir, |
| At line 231 added 254 lines |
| I followed your use cases links above, but only found one page that used hyphens for dialog, and those had spaces in front of the hyphens anyway, so they wouldn't be affected by our hyphenated lists. The one case I found is here: [[http://eversea.org/cgi-bin/wiki.pl?Nancy]]. Funny that I couldn't find many considering that it's "not an edge case". Perhaps in Polish dialog is indicated by hyphens whereas it is not in other languages. I've personally never remember seeing this in the fiction I've read. |
|
| As for indenting lists, we've already ruled that out due to InvisibleMarkup, so I will not even address that. |
|
| As for putting spaces after the asterisk, you have even seen in your own research that 25% of users do not put a space after the asterisk of a list, so I also don't see how this could be a solution. |
|
| Which of the following is clearer? |
|
| {{{ |
| * **Older programming languages** |
| ** **Prolog:** for AI |
| ** **Cobol:** for business |
| * **Modern programming languages** |
| ** **Java** popular cross-platform solution |
| ** **Python** popular for text processing |
| ** **Ruby** invented in Japan |
| }}} |
|
| {{{ |
| - **Older programming languages** |
| -- **Prolog:** for AI |
| -- **Cobol:** for business |
| - **Modern programming languages** |
| -- **Java** popular cross-platform solution |
| -- **Python** popular for text processing |
| -- **Ruby** invented in Japan |
| }}} |
|
| As far as beauty, I think the second example definitely is more beautiful, but people could argue forever on which markup is aesthetically more beautiful. That's mostly a matter of taste. I know the head developer of MoinMoin finds Creole distasteful because it is ugly, but I personally find MoinMoin's syntax very ugly. Also, when people start using wikis, I have often seen that they try to use hyphens for lists instead of asterisks. |
|
| I would, however, really like to hear other developer's opinions on this issue rather than just us three. What are others' opinions? |
|
| -- [[ChuckSmith]], 2007-Feb-27 |
|
| ---- |
|
| Gripes with current proposals: |
| * Current standard: having to escape the (quite common) "bold at the beginning of a line" is bad. |
| ** So: Should my proposal prove inadequate (or unpopular ;-) I'm very much in favor of this proposal. Still: Strange escaping rules should be avoided at all costs. |
| * Repeating the bullet character (vs. whitespace): I am not sure that we are not making common things (at most 2 indentation levels in lists) harder while making uncommon things (more than 2 nesting levels) easier. |
|
| I'm in favor of the following syntax (hear me out, I'll consider anti-whitespace arguments) |
| {{{ |
| - one (ul) |
| - one.one |
| - one.two |
| - two (ul) |
| + two.one (ol) |
| }}} |
|
| Advantages: |
| * Uniform: ordered and unordered lists have similar "bullets". |
| * WYSIWY: Commonly used in plain text, looks a lot like the rendered output. |
| * Clash with hr: not an issue. |
| * Clash with signature: not an issue. |
| * Works quite well in Python and Haskell. This point is only partly humorous, as wiki markup is a semi-formal language and does have some rigid rules, so the same kind of usability rules apply here as they do to programming languages. |
|
| Potential disadvantages: |
|
| * User has to count spaces: I would count ''relative'' indentation (not the absolute amount of spaces), then this is only a problem if one wants to continue a second-level list (see below). But: users look for visual feedback after entering wiki text, anyway, and will be very obviously alerted to the problem then. |
| {{{ |
| - first level |
| - second level (counting is not a problem: we just have MORE spaces than the line above) |
| - third level 1 |
| - third level 2 (counting is not a problem: it is the same as the line above) |
| - second level continued (here we have to count...) |
| }}} |
| * Confusing tabs and spaces: disallow tabs. |
| * Clash with negative numbers: make space after hyphen mandatory. |
|
| -- AxelRauschmayer, 2007-02-28 |
|
| I think that we have enough material to create a [[ListMarkupAlternatives]] page and try to summarize everything we have scattered around. Even if we don't come up with a good solution, we will at least have one good place to point people to. |
|
| The list markup has a lot of space for being creative and a lot of interesting features -- this invites [[Bikeshedding]]. What I'd like to propose is to allow a little creativity, put the propositions on that page, describe the good and bad things about them, compare them, etc. and then leave it to cool down a little (several days maybe) -- I'm sure that the one obvious solution will appear then :). |
|
| -- [[Radomir Dopieralski]] |
|
| Excellent idea! I am all to familiar with bikeshedding urges, myself, so the cooling down period makes a lot of sense. I've started to put my ideas on [[ListMarkupAlternatives]]. |
|
| -- AxelRauschmayer, 2007-02-29 |
|
| Moved this potential disadvantages to discussion: |
|
| ''ambiguities in languages using dash with blanks before and after, such as German. -- As long as new lines may be part of paragraph, this will lead to random occurrences of hyphen in first line by any line-wrapping editor client. In the wikis I know, lists are commonly written **without** blank lines before and after.'' |
|
| Don't understand. If a line wrapping client wraps a line, it will not put a hard coded line break in. So this does not create a random occurence. If you write german, at least I never put the dash at the beginning of a line if it occurs that I have to hard break the line, I always put it on the end: |
|
| {{{ |
| Here's a German sentence: |
|
| Dies ist ein Gedankenstrich - |
| so etwas kommt vor. |
|
| I usually don't use this (Question is: does some grammatical rule forbid it?) |
|
| Dies ist ein Gedankenstrich |
| - so etwas kommt vor |
|
| You would never separate a word like this |
|
| Dies ist eine Sauerstoff |
| -flasche. |
|
| You would hard break the line after the dash, not before it: |
|
| Dies ist eine Sauerstoff- |
| flasche. |
|
| }}} |
|
| So I guess the second example might happen, but it's very rare and could be easily resolved, by using the order of the first sentence. |
|
| --[[Christoph Sauer]], 2007-Mar-06 |
|
| In plain text, there are only hard breaks, at least with the text editors I know. "Soft" |
| breaks aren't encoded; they just appear in some text editors or text edit fields. So |
| hyphen can be a problem when the client forces automatic hard word wrap, like equal signs |
| (e.g. if the equal sign of equation a = 2 wraps to the beginning of a line). We can |
| probably accept it. |
|
| -- [[YvesPiguet]], 2007-Mar-06 |
|
| I've added a page called [[List Markup Linebreak Argument]] since it repeatedly appeared, to discuss it there. |
|
| --[[Christoph Sauer]], 2007-Apr-14 |
|
| ------------------ |
|
| Note that multiple dash/minus characters for nested list are actually a new invention -- only used in PukiWiki, together with other exotic markup: "*" for headlines, ">" in links, "%" for underline and strike, &ref(...) for images. |
|
| I'm all for allowing a "hyphen list" -- it *is* traditional and intuitive. I'm just against multiple dashes for nesting: to me it is totally arbitrary, new invention, looks ugly and doesn't really suggest the meaning. |
|
| As for rules for word wrapping (hyphenation), you only leave the dash at the right margin on the previous line. Most style guides advice to avoid breaking of hyphenated words, and if you must, to break them somewhere else than the hyphen. For the cases where you absolutely need to break a word at the hyphen there is this rare "double hyphen" glyph, looking like an equal sign: I was wrong about the repeating the hyphen on the next line. |
|
| This leaves us with only a few cases of when a hyphen can appear at the beginning of a line (and it cannot be avoided): |
| * when the paragraph starts with a suffix: |
| {{{ |
| "-cious is the ending of both precious and spacious." |
| }}} |
| * when the paragraph starts with a negative number: |
| {{{ |
| "-1 is a negative number" |
| }}} |
| * when someone writes a dialog and uses "-" instead of dashes for simplicity: |
| {{{ |
| "- Yes - said John." |
| }}} |
| Requiring a space after the minus solves two first cases. Using proper dashes, real ones or the "--" abbreviation, solves the first and the last one. |
|
| -- [[Radomir Dopieralski]], 2007-Mar-08 |
|
| Radomir, since you're doing an experiment with your students and you've implemented |
| Creole 0.5, have you got feedback on that star confusion? |
|
| Personally, I don't see a problem that needs to be fixed here. We shouldn't forget {{{##}}} |
| either. |
|
| -- [[YvesPiguet]], 2007-Mar-08 |
|
| The experiment is running, the students had 2 classes so far -- they haven't had to **write** anything to the wiki yet, so it's going kind of slow. I will have a different occasion soon -- another group of students will be writing an exam online, and the teacher wants them to use a wiki for that -- this will be one-time event, so they will have to just read the cheatsheet and start writing right away, concentrating on the content not on the formatting. |
|
| I will open both wikis for viewing once the experiment is done. Right now the access remains restricted so that the students can't cheat and copy each other's work. |
|
| -- [[Radomir Dopieralski]], 2007-Mar-08 |
|
| Ok, thanks. -- [[YvesPiguet]], 2007-Mar-08 |
|
| I propose to //reject// this proposal, for the following reasons: |
| * star is less common than hyphen in normal text (dialogs and negative numbers); |
| * if the ambiguity with bold markup is really a problem (which I don't think it is), then the ambiguity between numbered lists and monospace should also be discussed now, so that we don't have to regret this decision; |
| * we're running out of markup characters, so it'll be difficult to avoid all ambiguities; since this one and {{{#}}}/{{{##}}} are harmless, we should accept them. |
|
| -- [[YvesPiguet]], 2007-Mar-21 |
|
| //keep// - All my developers tell me (WikiWizard Project, CreolePageFilter) that it is easier to implement. Radomir seems to have problems too, otherwise he would not propose the space after bullet. Users instinctively use hyphens in list, I see it all the time - (e.g. just recently this one: [[http://www.marktberolzheim.de/Wiki.jsp?page=HVNews_blogentry_110307_1]]). The [People] at the WMS Workshop wanted it. Yves, it seems that your parser is pretty advanced so you don't have problems with it, but others have. It helps to make implementations easier and does not hurt the eye of the beholder (as {{{'''''}}} or {{{** *}}} does). Please keep your implementation and allow asterisk in lists additionally, but the least common denominator should be hyphens for lists. |
|
| Yes, we are running out of markup characters, but as long as we can afford it, we should avoid using the same characters, and this proposal does not introduce a new one - the rule of the frequency of usage is very important here: we can have same markup for rare combinations, but not for bold and lists. |
|
| -- [[ChristophSauer]], 2007-Mar-21 |
|
| Radomir's implementation for MoinMoin passed the [[BoldAndListsAmbiguity]] test... |
| Hyphens would require to use the context to disambiguate lists and signatures, so I'm |
| not sure to understand why the implementation would be simpler. |
|
| I much prefer a single markup character for unordered lists to offering both, so I'll |
| switch completely if this proposal is accepted for 0.6. But what do you suggest for {{{##}}}? |
| I think that separating nowiki and monospace is important (we could give up inline |
| nowiki if we accept an escape character, but monospace as a normal style is highly |
| needed, imo). |
|
| Another way to disambiguate {{{**}}} and {{{##}}} would be to always consider them as |
| list markup when they are at the beginning of a line and as style markup elsewhere, |
| e.g. after a space. |
|
| -- [[YvesPiguet]], 2007-Mar-21 |
|
| Except sometimes you'd want to put emphasis ({{{**}}}) on a whole paragraph... |
| If I understood your idea, Yves, it wouldn't be possible anymore. Right? |
|
| -- [[MicheleTomaiuolo]], 2007-03-22 |
|
| No, I meant something like that: |
|
| {{{ |
| A list: |
| ** a single level-2 |
| item spanning two lines |
|
| ** Very important note: style is reset at the |
| end of each paragraph! |
| }}} |
|
| Skipping level-1 list is just for the sake of illustration. Spaces at the beginning or end |
| of lines should be discarded anyway (if they aren't by the Creole parser, I guess they are |
| anyway in HTML). That should be easy to implement with regexps. |
|
| I don't want to restart a whole discussion if everyone agreed on hyphens, though... |
|
| -- [[YvesPiguet]], 2007-03-22 |
|
| People do commonly indent lists, especially second-level nested lists. Also the choice of which one is a list and which is bold seems pretty arbitrary, no? Then again, the meaning of this is easier to guess: |
|
| {{{ |
| A list: |
| ** a single level-2 |
| item spanning two lines |
|
| **Very important note: style is reset at the |
| end of each paragraph! |
| }}} |
|
| -- [[Radomir Dopieralski]], 2007-Mar-22 |
|
| It's done neither in Mediawiki where indenting is used for preformatted blocks, nor in |
| WikiCreole. I don't have experience with other engines. Edge cases are often unintuitive, whatever |
| we choose; that's why I insist on simple and consistent rules. I wouldn't mind your proposition |
| if so many WikiPedia lists hadn't any space. Actually, I don't really dislike it :-) |
|
| -- [[YvesPiguet]], 2007-Mar-22 |
|
| I don't think {{{##}}} would be much of an issue, because I wouldn't expect monospace to be used much at the beginning of numbered lists. However, as Radomir's research suggests, bold is quite common at the beginning of list items. Also, keep in mind that some wiki engines like [[TracWiki]] even require a space before the asterisk or number sign. |
|
| -- [[Chuck Smith]], 2007-Mar-22 |
|
| To be honest, I really liked the original Creole proposal: No nested lists. And thus my first Creole implementation supported * and - for lists, and there was no discussion about nesting. Great! :) |
|
| -- AlexSchroeder, 2007-04-03 |
|
| Christoph wrote: //If you turn on line wrap in an editor, the editor will visually wrap the line. You will find this behavior in almost all editors. Those editors however do NOT insert hard line breaks, that could be confused by parsers so that they make the errors above -- they only do it visually. So far no one has brought up examples of such an editor, or editor option, that inserts hard line breaks into text. Therefore this is considered as an irrelevant argument unless someone provides an example of an editor that is relevant in practice.// |
|
| On Macintosh, text editors BBEdit (commercial) and [[http://www.barebones.com/products/textwrangler/index.shtml|TextWrangler]] (free) have such an option. |
|
| -- [[YvesPiguet]], 2007-04-17 |
.