Anca Paula Luca wrote:

Thomas Mortagne wrote:

...

Hi devs,

We have to make a decision about that.

So here are the proposals:

1) remove the block leading and trainling spaces * The main goal is to make source formatting for tables for example more readable

2) make the spaces inside paragraph non meaningfull * Meaning an HTML like behavior where multiple spaces give one space

3) in case of 1) or 2) use ~<space> as non breaking space

WDYT ?

I'd go for a consistent approach, same behaviour in all situations so that it's not hard to know what to expect. I had some trouble defining "block elements" for myself so that I can answer this email so I assume it would be difficult for users too. Therefore either 1) and 2) together or none.

Now since wiki syntax is not supposed to be "what you see is what you get" but more of a markup language, I think non-meaningful spaces would be a acceptable (the HTML way) as long as there is a method to force a non-breaking space (HTML's  ).

So +1 for 1) 2) and 3)

Same.

...

+0,5 for 1) it's not critical for me but i'm not against it and we already decided to remove space before list item, headers etc. -0 for 2) I don't see the need for that and it's a lot easier for the parser to make spaces meaningfull (what to do when you have "test ** bold**" and things like that) +1 for 3)

On Sat, Feb 28, 2009 at 15:44, Vincent Massol <[email protected]> wrote:

...

Hi,

This is our last chance to change this behavior. We've found several places where having meaningful spaces are counter-productive:

* in table cells since we can't align table anymore. For example:

|= column1 |= column2 | this is some para | second column | hello | world

(not sure this will be rendered nicely in mail but you see what I mean)

* in scripts since having meaningful spaces prevents us from aligning velocity or groovy scripts. For ex we can't write:

#if (....) #if (...) do something # end #end

To see a better example have a look at http://tinyurl.com/ahz669

What I think users real want are meaningful new lines but I see cons overweighting pros for having meaningful white spaces. Thus I'm think we should strip whitespaces at beginning and end of lines including for line breaks. I'm slightly less sure for multiple spaces between words but even there I think we could strip them have users use {{{ }}} to put a non breaking space for ex (or introduce a {{space/}} macro or another special syntax although I'd rather we don't introduce a new syntax).

WDYT?

-- Sergiu Dumitriu http://purl.org/net/sergiu/

Marius Dumitru Florea wrote:

Thomas Mortagne wrote:

...

Hi devs,

We have to make a decision about that.

So here are the proposals:

1) remove the block leading and trainling spaces * The main goal is to make source formatting for tables for example more readable

2) make the spaces inside paragraph non meaningfull * Meaning an HTML like behavior where multiple spaces give one space

3) in case of 1) or 2) use ~<space> as non breaking space

WDYT ?

-0, the users will blame the WYSIWYG for messing up their nicely formatted table/lists/etc. when switching between the editors. This will make the WYSIWYG unusable for a wiki syntax user.

Why? The renderer should leave spaces as they are, the WYSIWYG editor should not care about them, and the parser should just leave white space alone. ~space is the only one that must be transformed and treaded specially.

...

+0,5 for 1) it's not critical for me but i'm not against it and we already decided to remove space before list item, headers etc. -0 for 2) I don't see the need for that and it's a lot easier for the parser to make spaces meaningfull (what to do when you have "test ** bold**" and things like that) +1 for 3)

On Sat, Feb 28, 2009 at 15:44, Vincent Massol <[email protected]> wrote:

...

Hi,

This is our last chance to change this behavior. We've found several places where having meaningful spaces are counter-productive:

* in table cells since we can't align table anymore. For example:

|= column1 |= column2 | this is some para | second column | hello | world

(not sure this will be rendered nicely in mail but you see what I mean)

* in scripts since having meaningful spaces prevents us from aligning velocity or groovy scripts. For ex we can't write:

#if (....) #if (...) do something # end #end

To see a better example have a look at http://tinyurl.com/ahz669

What I think users real want are meaningful new lines but I see cons overweighting pros for having meaningful white spaces. Thus I'm think we should strip whitespaces at beginning and end of lines including for line breaks. I'm slightly less sure for multiple spaces between words but even there I think we could strip them have users use {{{ }}} to put a non breaking space for ex (or introduce a {{space/}} macro or another special syntax although I'd rather we don't introduce a new syntax).

WDYT?

Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

-- Sergiu Dumitriu http://purl.org/net/sergiu/

Anca Paula Luca wrote:

Sergiu Dumitriu wrote:

...

Marius Dumitru Florea wrote:

...

Thomas Mortagne wrote:

...

Hi devs,

We have to make a decision about that.

So here are the proposals:

1) remove the block leading and trainling spaces * The main goal is to make source formatting for tables for example more readable

2) make the spaces inside paragraph non meaningfull * Meaning an HTML like behavior where multiple spaces give one space

3) in case of 1) or 2) use ~<space> as non breaking space

WDYT ? -0, the users will blame the WYSIWYG for messing up their nicely formatted table/lists/etc. when switching between the editors. This will make the WYSIWYG unusable for a wiki syntax user.

Why? The renderer should leave spaces as they are, the WYSIWYG editor should not care about them, and the parser should just leave white space alone. ~space is the only one that must be transformed and treaded specially.

The wysiwyg is sending back the rendered html modified i.e. without non-meaningful spaces => the spaces added for nice wiki formatting will be lost.

Yes: | cell | => <td>cell</td> => |cell| Adding meta data to keep spaces is crazy: | cell | => <td><!--ws:3-->cell<!--ws:3--></td> => | cell | Marius

...

...

...

+0,5 for 1) it's not critical for me but i'm not against it and we already decided to remove space before list item, headers etc. -0 for 2) I don't see the need for that and it's a lot easier for the parser to make spaces meaningfull (what to do when you have "test ** bold**" and things like that) +1 for 3)

On Sat, Feb 28, 2009 at 15:44, Vincent Massol <[email protected]> wrote:

...

Hi,

This is our last chance to change this behavior. We've found several places where having meaningful spaces are counter-productive:

* in table cells since we can't align table anymore. For example:

|= column1 |= column2 | this is some para | second column | hello | world

(not sure this will be rendered nicely in mail but you see what I mean)

* in scripts since having meaningful spaces prevents us from aligning velocity or groovy scripts. For ex we can't write:

#if (....) #if (...) do something # end #end

To see a better example have a look at http://tinyurl.com/ahz669

What I think users real want are meaningful new lines but I see cons overweighting pros for having meaningful white spaces. Thus I'm think we should strip whitespaces at beginning and end of lines including for line breaks. I'm slightly less sure for multiple spaces between words but even there I think we could strip them have users use {{{ }}} to put a non breaking space for ex (or introduce a {{space/}} macro or another special syntax although I'd rather we don't introduce a new syntax).

WDYT?

Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Anca Paula Luca wrote:

Anca Paula Luca wrote:

...

Sergiu Dumitriu wrote:

...

Marius Dumitru Florea wrote:

...

Thomas Mortagne wrote:

...

Hi devs,

We have to make a decision about that.

So here are the proposals:

1) remove the block leading and trainling spaces * The main goal is to make source formatting for tables for example more readable

2) make the spaces inside paragraph non meaningfull * Meaning an HTML like behavior where multiple spaces give one space

3) in case of 1) or 2) use ~<space> as non breaking space

WDYT ? -0, the users will blame the WYSIWYG for messing up their nicely formatted table/lists/etc. when switching between the editors. This will make the WYSIWYG unusable for a wiki syntax user.

Why? The renderer should leave spaces as they are, the WYSIWYG editor should not care about them, and the parser should just leave white space alone. ~space is the only one that must be transformed and treaded specially. The wysiwyg is sending back the rendered html modified i.e. without non-meaningful spaces => the spaces added for nice wiki formatting will be lost.

I hurried a bit with the answer, indeed we can rely on the html processing of spaces in browsers and *not* strip them off on rendering time, so that we can pass them safely through the rendered html.

Actually I don't think it would work, because wysiwyg is working with a DOM build from the rendered content, which is then serialized and sent back as the edited content. I don't think browsers parse and store non-meaningfull spaces in DOM, nor serialize them back.

Still I think the parser would have a problem with reconstructing them in non-meaningfull text elements (as in before list items).

...

...

...

...

+0,5 for 1) it's not critical for me but i'm not against it and we already decided to remove space before list item, headers etc. -0 for 2) I don't see the need for that and it's a lot easier for the parser to make spaces meaningfull (what to do when you have "test ** bold**" and things like that) +1 for 3)

On Sat, Feb 28, 2009 at 15:44, Vincent Massol <[email protected]> wrote:

...

Hi,

This is our last chance to change this behavior. We've found several places where having meaningful spaces are counter-productive:

* in table cells since we can't align table anymore. For example:

|= column1 |= column2 | this is some para | second column | hello | world

(not sure this will be rendered nicely in mail but you see what I mean)

* in scripts since having meaningful spaces prevents us from aligning velocity or groovy scripts. For ex we can't write:

#if (....) #if (...) do something # end #end

To see a better example have a look at http://tinyurl.com/ahz669

What I think users real want are meaningful new lines but I see cons overweighting pros for having meaningful white spaces. Thus I'm think we should strip whitespaces at beginning and end of lines including for line breaks. I'm slightly less sure for multiple spaces between words but even there I think we could strip them have users use {{{ }}} to put a non breaking space for ex (or introduce a {{space/}} macro or another special syntax although I'd rather we don't introduce a new syntax).

WDYT?

Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Anca Paula Luca wrote:

Marius Dumitru Florea wrote:

...

Thomas Mortagne wrote:

...

Hi devs,

We have to make a decision about that.

So here are the proposals:

1) remove the block leading and trainling spaces * The main goal is to make source formatting for tables for example more readable

2) make the spaces inside paragraph non meaningfull * Meaning an HTML like behavior where multiple spaces give one space

3) in case of 1) or 2) use ~<space> as non breaking space

WDYT ? -0, the users will blame the WYSIWYG for messing up their nicely formatted table/lists/etc. when switching between the editors. This will make the WYSIWYG unusable for a wiki syntax user.

1/ this problem was there already

with the old syntax I meant

and, if we use meaningful spaces, we only get rid of the problem because users wouldn't be able to nicely format the tables/lists/etc at all. So meaningful spaces means that you're taking away the possibility of nicely formated wiki syntax even to users that use _only_ wiki syntax and therefore could take advantage of it.

2/ as it was mentioned in a discussion we once had with Vincent, I'm wondering how many wiki syntax users will there be out there once we get the new wysiwyg strong enough. Otherwise put, is this use-case frequent enough?

Happy coding, Anca

...

Marius

...

+0,5 for 1) it's not critical for me but i'm not against it and we already decided to remove space before list item, headers etc. -0 for 2) I don't see the need for that and it's a lot easier for the parser to make spaces meaningfull (what to do when you have "test ** bold**" and things like that) +1 for 3)

On Sat, Feb 28, 2009 at 15:44, Vincent Massol <[email protected]> wrote:

...

Hi,

This is our last chance to change this behavior. We've found several places where having meaningful spaces are counter-productive:

* in table cells since we can't align table anymore. For example:

|= column1 |= column2 | this is some para | second column | hello | world

(not sure this will be rendered nicely in mail but you see what I mean)

* in scripts since having meaningful spaces prevents us from aligning velocity or groovy scripts. For ex we can't write:

#if (....) #if (...) do something # end #end

To see a better example have a look at http://tinyurl.com/ahz669

What I think users real want are meaningful new lines but I see cons overweighting pros for having meaningful white spaces. Thus I'm think we should strip whitespaces at beginning and end of lines including for line breaks. I'm slightly less sure for multiple spaces between words but even there I think we could strip them have users use {{{ }}} to put a non breaking space for ex (or introduce a {{space/}} macro or another special syntax although I'd rather we don't introduce a new syntax).

WDYT?

Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, On Thu, Mar 5, 2009 at 8:01 PM, Jerome Velociter <[email protected]> wrote:

Anca Paula Luca wrote:

...

Anca Paula Luca wrote:

...

Marius Dumitru Florea wrote:

...

Thomas Mortagne wrote:

...

Hi devs,

We have to make a decision about that.

So here are the proposals:

1) remove the block leading and trainling spaces * The main goal is to make source formatting for tables for example more readable

2) make the spaces inside paragraph non meaningfull * Meaning an HTML like behavior where multiple spaces give one space

3) in case of 1) or 2) use ~<space> as non breaking space

WDYT ? -0, the users will blame the WYSIWYG for messing up their nicely formatted table/lists/etc. when switching between the editors. This will make the WYSIWYG unusable for a wiki syntax user. 1/ this problem was there already

with the old syntax I meant

...

and, if we use meaningful spaces, we only get rid of the problem because users wouldn't be able to nicely format the tables/lists/etc at all. So meaningful spaces means that you're taking away the possibility of nicely formated wiki syntax even to users that use _only_ wiki syntax and therefore could take advantage of it.

2/ as it was mentioned in a discussion we once had with Vincent, I'm wondering how many wiki syntax users will there be out there once we get the new wysiwyg strong enough.

There always will be developers for that (even if not necessarily through the wiki editor but rather through XEclipse or bespin's editor). I have doubts about scripting velocity or groovy in a dialog box in the wysiwyg :)

My 2 cents, Jerome.

After thinking a bit more about it, here's my updated point of view: 1. Developers are mostly the only ones who will care about nice syntax formatting in the wiki editor 2. We are working hard to make our wiki easier to use for business users 3. Developers are advanced user thus able to make their way round whether ot not spaces are meaningful in wiki syntax 4. Apart from them, almost nobody cares about nicely aligned tables and indented code 5. As Jérôme pointed it out, developers will use other tools than the wiki editor anyway when developing 6. Thus we're basically fighting with a non-issue: trying to preserve a feature that does not matter for the user base we need to convince our wiki is the greatest around (*business users* are the *core users* of an *enterprise wiki*) So here's my updated vote: *I'm -1 for making spaces non-meaningful, either in the WYSIWYG or the wiki editor.* If developers want nifty development features and great-looking code, we need to provide them with actual development tools (Eclipse, XEclipse, Bespin). Business users don't care about that and they expect to have what you see is what you get: a space when writing is a space on screen once saved, be it in WYSIWYG editor or in wiki syntax. Thanks to everybody's feedback, Guillaume

...

Otherwise put, is this use-case frequent enough?

Happy coding, Anca

...

Marius

...

+0,5 for 1) it's not critical for me but i'm not against it and we already decided to remove space before list item, headers etc. -0 for 2) I don't see the need for that and it's a lot easier for the parser to make spaces meaningfull (what to do when you have "test ** bold**" and things like that) +1 for 3)

On Sat, Feb 28, 2009 at 15:44, Vincent Massol <[email protected]> wrote:

...

Hi,

This is our last chance to change this behavior. We've found several places where having meaningful spaces are counter-productive:

* in table cells since we can't align table anymore. For example:

|= column1 |= column2 | this is some para | second column | hello | world

(not sure this will be rendered nicely in mail but you see what I mean)

* in scripts since having meaningful spaces prevents us from aligning velocity or groovy scripts. For ex we can't write:

#if (....) #if (...) do something # end #end

To see a better example have a look at http://tinyurl.com/ahz669

What I think users real want are meaningful new lines but I see cons overweighting pros for having meaningful white spaces. Thus I'm think we should strip whitespaces at beginning and end of lines including for line breaks. I'm slightly less sure for multiple spaces between words but even there I think we could strip them have users use {{{ }}} to put a non breaking space for ex (or introduce a {{space/}} macro or another special syntax although I'd rather we don't introduce a new syntax).

WDYT?

Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/

Vincent Massol wrote:

On Fri, Mar 6, 2009 at 3:23 AM, Guillaume Lerouge <[email protected]> wrote:

...

Hi,

On Thu, Mar 5, 2009 at 8:01 PM, Jerome Velociter <[email protected]> wrote:

...

Anca Paula Luca wrote:

...

Anca Paula Luca wrote:

...

Marius Dumitru Florea wrote:

...

Thomas Mortagne wrote: > Hi devs, > > We have to make a decision about that. > > So here are the proposals: > > 1) remove the block leading and trainling spaces > * The main goal is to make source formatting for tables for example > more readable > > 2) make the spaces inside paragraph non meaningfull > * Meaning an HTML like behavior where multiple spaces give one space > > 3) in case of 1) or 2) use ~<space> as non breaking space > > WDYT ? -0, the users will blame the WYSIWYG for messing up their nicely formatted table/lists/etc. when switching between the editors. This will make the WYSIWYG unusable for a wiki syntax user. 1/ this problem was there already with the old syntax I meant

...

and, if we use meaningful spaces, we only get rid of the problem because users wouldn't be able to nicely format the tables/lists/etc at all. So meaningful spaces means that you're taking away the possibility of nicely formated wiki syntax even to users that use _only_ wiki syntax and therefore could take advantage of it.

2/ as it was mentioned in a discussion we once had with Vincent, I'm wondering how many wiki syntax users will there be out there once we get the new wysiwyg strong enough. There always will be developers for that (even if not necessarily through the wiki editor but rather through XEclipse or bespin's editor). I have doubts about scripting velocity or groovy in a dialog box in the wysiwyg :)

My 2 cents, Jerome.

After thinking a bit more about it, here's my updated point of view:

1. Developers are mostly the only ones who will care about nice syntax formatting in the wiki editor 2. We are working hard to make our wiki easier to use for business users

This points has nothing to do with the discussion. WYSIWYG wouldn't be changed.

...

3. Developers are advanced user thus able to make their way round whether ot not spaces are meaningful in wiki syntax

No. Definitely not. I cannot make my way around page content I cannot read/write.

...

4. Apart from them, almost nobody cares about nicely aligned tables and indented code

Not true at all. Lots of users are not technical users but like the wiki syntax and are used to it. For these users they care about alignments.

...

5. As Jérôme pointed it out, developers will use other tools than the wiki editor anyway when developing

Again not true at all. The strength of the xwiki model is to be able to develop in pages. I do that all the time and most advanced users do the same.

Yes it's a strength to be able to wire up scripts and small apps directly from the wiki editor. However, for more lengthy wiki development, you want to use a real script editor like XEclipse. In the end this question is not even relevant, the concerned editors being also text editors, if you lose space formatting, its lost for them too.

...

6. Thus we're basically fighting with a non-issue: trying to preserve a feature that does not matter for the user base we need to convince our wiki is the greatest around (*business users* are the *core users* of an *enterprise wiki*)

I don't know where you've seen that we would make spaces non meaningful in the WYSIWYG editor.

...

So here's my updated vote:

*I'm -1 for making spaces non-meaningful, either in the WYSIWYG or the wiki editor.*

Please reconsider as I don't think you're making a correct evaluation. See the items above, your premises are not correct: we're NOT talking about changing the WYSIWYG for non technical users.

...

If developers want nifty development features and great-looking code, we need to provide them with actual development tools (Eclipse, XEclipse, Bespin). Business users don't care about that and they expect to have what you see is what you get: a space when writing is a space on screen once saved, be it in WYSIWYG editor or in wiki syntax.

This is completely not true for the wiki syntax. You're forgetting the purpose of the wiki syntax. Its goal is to be able to write quickly content. The written syntax must be clear and readable. It's not the case right now when you start using: tables, HTML and velocity scripts. It's a big problem, making xwiki unusable for all the places where it has strengths over other wikis. If you look at XE pages you'll see most of them contain either HTML or scripts and they are not readable and impossible to write.

I have always had doubts since the beginning for table syntax and not being able to align them as before but that alone wasn't enough to make me change my mind. However that coupled with the huge issue with writing scripts/HTML makes me completely convinced we cannot leave it as it is.

Totally agreed. Jerome

Thanks -Vincent

...

Thanks to everybody's feedback,

Guillaume

...

...

Otherwise put, is this use-case frequent enough?

Happy coding, Anca

...

Marius

...

+0,5 for 1) it's not critical for me but i'm not against it and we already decided to remove space before list item, headers etc. -0 for 2) I don't see the need for that and it's a lot easier for the parser to make spaces meaningfull (what to do when you have "test ** bold**" and things like that) +1 for 3)

On Sat, Feb 28, 2009 at 15:44, Vincent Massol <[email protected]> wrote: > Hi, > > This is our last chance to change this behavior. We've found several > places where having meaningful spaces are counter-productive: > > * in table cells since we can't align table anymore. For example: > > |= column1 |= column2 > | this is some para | second column > | hello | world > > (not sure this will be rendered nicely in mail but you see what I mean) > * in scripts since having meaningful spaces prevents us from aligning > velocity or groovy scripts. For ex we can't write: > > #if (....) > #if (...) > do something > # end > #end > > To see a better example have a look at http://tinyurl.com/ahz669 > > What I think users real want are meaningful new lines but I see cons > overweighting pros for having meaningful white spaces. Thus I'm think > we should strip whitespaces at beginning and end of lines including > for line breaks. > I'm slightly less sure for multiple spaces between words but even > there I think we could strip them have users use {{{ }}} to put a non > breaking space for ex (or introduce a {{space/}} macro or another > special syntax although I'd rather we don't introduce a new syntax). > > WDYT? > > Thanks > -Vincent > http://xwiki.com > http://xwiki.org > http://massol.net

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, On Fri, Mar 6, 2009 at 3:17 PM, Thomas Mortagne <[email protected]>wrote:

On Fri, Mar 6, 2009 at 10:11, Jerome Velociter <[email protected]> wrote:

...

Vincent Massol wrote:

...

On Fri, Mar 6, 2009 at 3:23 AM, Guillaume Lerouge <[email protected]> wrote:

...

Hi,

On Thu, Mar 5, 2009 at 8:01 PM, Jerome Velociter <[email protected]> wrote:

...

Anca Paula Luca wrote:

...

Anca Paula Luca wrote: > Marius Dumitru Florea wrote: >> Thomas Mortagne wrote: >>> Hi devs, >>> >>> We have to make a decision about that. >>> >>> So here are the proposals: >>> >>> 1) remove the block leading and trainling spaces >>> * The main goal is to make source formatting for tables for example >>> more readable >>> >>> 2) make the spaces inside paragraph non meaningfull >>> * Meaning an HTML like behavior where multiple spaces give one space >>> >>> 3) in case of 1) or 2) use ~<space> as non breaking space >>> >>> WDYT ? >> -0, the users will blame the WYSIWYG for messing up their nicely >> formatted table/lists/etc. when switching between the editors. This will >> make the WYSIWYG unusable for a wiki syntax user. > 1/ this problem was there already with the old syntax I meant

> and, if we use meaningful spaces, we only get > rid of the problem because users wouldn't be able to nicely format the > tables/lists/etc at all. So meaningful spaces means that you're taking away the > possibility of nicely formated wiki syntax even to users that use _only_ wiki > syntax and therefore could take advantage of it. > > 2/ as it was mentioned in a discussion we once had with Vincent, I'm wondering > how many wiki syntax users will there be out there once we get the new wysiwyg > strong enough. There always will be developers for that (even if not necessarily through the wiki editor but rather through XEclipse or bespin's editor). I have doubts about scripting velocity or groovy in a dialog box in the wysiwyg :)

My 2 cents, Jerome.

After thinking a bit more about it, here's my updated point of view:

1. Developers are mostly the only ones who will care about nice syntax formatting in the wiki editor 2. We are working hard to make our wiki easier to use for business users

This points has nothing to do with the discussion. WYSIWYG wouldn't be changed.

...

3. Developers are advanced user thus able to make their way round whether ot not spaces are meaningful in wiki syntax

No. Definitely not. I cannot make my way around page content I cannot read/write.

...

4. Apart from them, almost nobody cares about nicely aligned tables and indented code

Not true at all. Lots of users are not technical users but like the wiki syntax and are used to it. For these users they care about alignments.

...

5. As Jérôme pointed it out, developers will use other tools than the wiki editor anyway when developing

Again not true at all. The strength of the xwiki model is to be able to develop in pages. I do that all the time and most advanced users do the same.

Yes it's a strength to be able to wire up scripts and small apps directly from the wiki editor. However, for more lengthy wiki development, you want to use a real script editor like XEclipse. In the end this question is not even relevant, the concerned editors being also text editors, if you lose space formatting, its lost for them too.

...

...

6. Thus we're basically fighting with a non-issue: trying to preserve a feature that does not matter for the user base we need to convince our wiki is the greatest around (*business users* are the *core users* of an *enterprise wiki*)

I don't know where you've seen that we would make spaces non meaningful in the WYSIWYG editor.

...

So here's my updated vote:

*I'm -1 for making spaces non-meaningful, either in the WYSIWYG or the wiki editor.*

Please reconsider as I don't think you're making a correct evaluation. See the items above, your premises are not correct: we're NOT talking about changing the WYSIWYG for non technical users.

...

If developers want nifty development features and great-looking code, we need to provide them with actual development tools (Eclipse, XEclipse, Bespin). Business users don't care about that and they expect to have what you see is what you get: a space when writing is a space on screen once saved, be it in WYSIWYG editor or in wiki syntax.

This is completely not true for the wiki syntax. You're forgetting the purpose of the wiki syntax. Its goal is to be able to write quickly content. The written syntax must be clear and readable. It's not the case right now when you start using: tables, HTML and velocity scripts. It's a big problem, making xwiki unusable for all the places where it has strengths over other wikis. If you look at XE pages you'll see most of them contain either HTML or scripts and they are not readable and impossible to write.

I have always had doubts since the beginning for table syntax and not being able to align them as before but that alone wasn't enough to make me change my mind. However that coupled with the huge issue with writing scripts/HTML makes me completely convinced we cannot leave it as it is.

Totally agreed.

Jerome

...

Thanks -Vincent

...

Thanks to everybody's feedback,

Guillaume

...

...

Otherwise put, is this use-case frequent enough?

Happy coding, Anca

> Marius > >> +0,5 for 1) it's not critical for me but i'm not against it and we >> already decided to remove space before list item, headers etc. >> -0 for 2) I don't see the need for that and it's a lot easier for

the

...

...

...

...

>> parser to make spaces meaningfull (what to do when you have "test ** >> bold**" and things like that) >> +1 for 3) >> >> On Sat, Feb 28, 2009 at 15:44, Vincent Massol <[email protected]> wrote: >>> Hi, >>> >>> This is our last chance to change this behavior. We've found several >>> places where having meaningful spaces are counter-productive: >>> >>> * in table cells since we can't align table anymore. For example: >>> >>> |= column1 |= column2 >>> | this is some para | second column >>> | hello | world >>> >>> (not sure this will be rendered nicely in mail but you see what I mean) >>> * in scripts since having meaningful spaces prevents us from aligning >>> velocity or groovy scripts. For ex we can't write: >>> >>> #if (....) >>> #if (...) >>> do something >>> # end >>> #end >>> >>> To see a better example have a look at http://tinyurl.com/ahz669 >>> >>> What I think users real want are meaningful new lines but I see cons >>> overweighting pros for having meaningful white spaces. Thus I'm think >>> we should strip whitespaces at beginning and end of lines including >>> for line breaks. >>> I'm slightly less sure for multiple spaces between words but even >>> there I think we could strip them have users use {{{ }}} to put a non >>> breaking space for ex (or introduce a {{space/}} macro or another >>> special syntax although I'd rather we don't introduce a new syntax). >>> >>> WDYT? >>> >>> Thanks >>> -Vincent >>> http://xwiki.com >>> http://xwiki.org >>> http://massol.net

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

I think we can extract 3 concepts from different conversations:

1) do nothing and let things as it is, meaning spaces are meaningful everywhere + nothing to do ;) - it's not possible to indent content in scripts like velocity or cleanly align tables for example

2) make spaces non-meaningful everywhere and have two different spaces in XDOM (space and non breaking space) for "readability" spaces to not desapear + it's easier to align and indent things everywhere - this means XDOM contains useless information for renderer - the user has to understand that when he write multiples space it will render only one - to not break spaces other than non breaking spaces when switching from WYSIWYG to wiki, we have to find a way to store the information in rendered XHTML

3) let spaces meaningful by default (in pure wiki content) and modify behavior by macros (like make spaces/new lines non meaningful for HTML macro etc...) + it's more logical for user that HTML macro content apply HTML behavior on spaces/newline and in the other hand in the simple wiki syntax it's easier to understand for user that 2 spaces will render 2 spaces - it's not possible to cleanly align table

Notes that spaces before list (<space><space>* item list) or headers and generally before standalone blocks, etc. are not part of the debate since this was already voted as part of the syntax.

WDYT ?

-1 for 1) I think we have to do something at least about indentation in scripts

+0 for 1) , I don't think it's such a big issue but I understand the need to make wiki syntax look nice.

-0 for 2) I really don't like the idea of having two different spaces in XDOM one of them being useless for renderer, for me it's look too much like a hack. Also I really think having non meaningful spaces does not makes much sense for users, I remember it was a difficult concept for me the first time I started to do HTML so I imagine how a user that knows nothing about HTML and don't want to can think about that.

-0 for 2) since it hides some bits of the syntax depending on whether the user is in wiki or wysiwyg mode.

+1 for 3) since the table align issue is not critical (it's the only "issue" I can think of for pure wiki content) and it makes lots of sense that HTML macros, Velocity macro and wiki content for example are very different contents and should have their own behavior on spaces and new lines. Also note that it's still possible align tables with spaces but this could not render exactly the same thing that non meaningful spaces (sometime the columns will be larger), it's a hack but it makes the table align issue a very small issue compared 2)

+1 for 3) as it uses simple behavior when in wiki syntax only (meaningful spaces + new lines respected), html-like behavior for new lines and white spaces when in the html macro and specific rules can be added to make code indentation possible in the velocity macro. Guillaume PS: and now I'm leaving ;-)

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/

On Mar 6, 2009, at 3:17 PM, Thomas Mortagne wrote: [snip]

I think we can extract 3 concepts from different conversations:

1) do nothing and let things as it is, meaning spaces are meaningful everywhere + nothing to do ;) - it's not possible to indent content in scripts like velocity or cleanly align tables for example

2) make spaces non-meaningful everywhere and have two different spaces in XDOM (space and non breaking space) for "readability" spaces to not desapear + it's easier to align and indent things everywhere - this means XDOM contains useless information for renderer - the user has to understand that when he write multiples space it will render only one - to not break spaces other than non breaking spaces when switching from WYSIWYG to wiki, we have to find a way to store the information in rendered XHTML

3) let spaces meaningful by default (in pure wiki content) and modify behavior by macros (like make spaces/new lines non meaningful for HTML macro etc...) + it's more logical for user that HTML macro content apply HTML behavior on spaces/newline and in the other hand in the simple wiki syntax it's easier to understand for user that 2 spaces will render 2 spaces - it's not possible to cleanly align table

Notes that spaces before list (<space><space>* item list) or headers and generally before standalone blocks, etc. are not part of the debate since this was already voted as part of the syntax.

WDYT ?

-1 for 1) I think we have to do something at least about indentation in scripts

-0 for 2) I really don't like the idea of having two different spaces in XDOM one of them being useless for renderer, for me it's look too much like a hack. Also I really think having non meaningful spaces does not makes much sense for users, I remember it was a difficult concept for me the first time I started to do HTML so I imagine how a user that knows nothing about HTML and don't want to can think about that.

+1 for 3) since the table align issue is not critical (it's the only "issue" I can think of for pure wiki content) and it makes lots of sense that HTML macros, Velocity macro and wiki content for example are very different contents and should have their own behavior on spaces and new lines. Also note that it's still possible align tables with spaces but this could not render exactly the same thing that non meaningful spaces (sometime the columns will be larger), it's a hack but it makes the table align issue a very small issue compared 2)

Some points: A) If the user sets the page syntax to a syntax that has non- meaningful spaces then the parser (wikimodel for ex) will surely remove these non meaningful spaces which means any round trip will loose them. The problem is that all other rendering engines don't usually do round tripping and don't have this notion of special spaces that are non meaningful. B) After discussing with thomas, we think we could add a new event in XWiki's rendering for this use case. Something like onMarker(MarkerType type, String markerString) that would be a generic marker event. This would be similar to the macro marker event we had and which I have removed not long ago (since it wasn't absolutely needed) and which could be added back in a more generic way. This would allow saving any kind of non-content information in the XDOM and allow the different renderers to decide what to do with them. Note that we would need to either make modifications to wikimodel's events (because of A)) or find ways around it. Need to think more about it. C) for the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser D) for the Velocity macro we have 2 choices I can think of: 1) strip all leading spaces for all lines. note that this means that inside a velocity macro you wouldn't be able to have a line break with the new line starting with spaces without escaping the leading space with ~(space). Note also that this means we will not be able to add extra new lines to format the text nicely (since that would add new paragraphs) or split a single line into several lines for extra readability. This is the case today with the old syntax and it's a pain not to be able to aerate the text with empty lines. Ex: some text next line #if (...) this goes on the same line #something(...) #end This is a new paragraph 2) strip all leading spaces for all lines + remove all new lines too. This means we need to ensure we still have one space remaining between "words" (same as HTML). The user would use something like $nl and $sp to explicitely enter new lines and spaces. The advantage is that you control completely the formatting (no magic anymore) at the cost of a little extra work (adding the $nl where required). Basically this means the same pros/cons as when you work with HTML where you need to explicitly add <br/> when you want new lines. Ex: some text $nl next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end $nl $nl This a new paragraph Note: I've aerated the text by putting extra new lines around the velocity #if to show that it would work. 3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line breaks with "//". The exact algorithm is: if there's 1 NL remove it, if there's more than 1 leave them. Ex: some text \\ next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end This a new paragraph E) We could have a special treatment for table cells and allow heading/ trailing spaces for cells. Note that this is easy to do but requires B) so that these spaces are kept when doing a round trip. F) Re stripping spaces before block elements as noted by Thomas I'd like to do that too before 1.8 except for paragraphs since otherwise this will cause problems with the wysiwyg and users won't be able to enter leading spaces in paragraphs. So I'm +1 with thomas's proposal number 3 above and I'm suggesting that for the moment we do only C) and D). For D) I'm hesitating between D) 2) and D) 3). WDYT? Thanks -Vincent

On Thu, Mar 5, 2009 at 5:55 PM, Anca Paula Luca <[email protected]> wrote:

Marius Dumitru Florea wrote:

...

Thomas Mortagne wrote:

...

Hi devs,

We have to make a decision about that.

So here are the proposals:

1) remove the block leading and trainling spaces * The main goal is to make source formatting for tables for example more readable

2) make the spaces inside paragraph non meaningfull * Meaning an HTML like behavior where multiple spaces give one space

3) in case of 1) or 2) use ~<space> as non breaking space

WDYT ?

-0, the users will blame the WYSIWYG for messing up their nicely formatted table/lists/etc. when switching between the editors. This will make the WYSIWYG unusable for a wiki syntax user.

1/ this problem was there already and, if we use meaningful spaces, we only get rid of the problem because users wouldn't be able to nicely format the tables/lists/etc at all. So meaningful spaces means that you're taking away the possibility of nicely formated wiki syntax even to users that use _only_ wiki syntax and therefore could take advantage of it.

2/ as it was mentioned in a discussion we once had with Vincent, I'm wondering how many wiki syntax users will there be out there once we get the new wysiwyg strong enough. Otherwise put, is this use-case frequent enough?

Everyone using the velocity or HTML macro are users of this use case. Right now it's not possible to write velocity scripts that can be read. Again see http://jira.xwiki.org/jira/browse/XWIKI-3107?focusedCommentId=37707&page=com... Thanks -Vincent [snip]