Anca Paula Luca wrote: Same. -- Sergiu Dumitriu http://purl.org/net/sergiu/

Marius Dumitru Florea wrote: 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. -- Sergiu Dumitriu http://purl.org/net/sergiu/

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

Anca Paula Luca wrote: 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.

Anca Paula Luca wrote: with the old syntax I meant

Hi, On Thu, Mar 5, 2009 at 8:01 PM, Jerome Velociter &lt;jerome(a)xwiki.com&gt; wrote: 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 wrote: mean) _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/

Vincent Massol wrote: 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. Totally agreed. Jerome

Hi, On Fri, Mar 6, 2009 at 3:17 PM, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com&gt;wrote;wrote: +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) since it hides some bits of the syntax depending on whether the user is in wiki or wysiwyg mode. +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 ;-) -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/

On Mar 6, 2009, at 3:17 PM, Thomas Mortagne wrote: [snip] 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 &lt;ancapaula.luca(a)xwiki.com&gt; wrote: 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&pag… Thanks -Vincent [snip]