Re: [xwiki-devs] [VOTE] Makes list content first spaces meaningful in XWiki 2.0 syntax (was Re: [Rendering 2.0][Vote] About whitespace management in list item context)

On Wed, Dec 17, 2008 at 3:12 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: > > On Dec 17, 2008, at 3:07 PM, Thomas Mortagne wrote: > >> On Wed, Dec 17, 2008 at 3:02 PM, Vincent Massol >> &lt;vincent(a)massol.net&gt; >> wrote: >>> >>> On Dec 17, 2008, at 2:38 PM, Thomas Mortagne wrote: >>> >>>> On Wed, Dec 17, 2008 at 1:15 PM, Vincent Massol &lt;vincent(a)massol.net >>>> > >>>> wrote: >>>>> >>>>> On Dec 17, 2008, at 12:57 PM, Lucien PEREIRA wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Working on annotation feature, I need to retrieve >>>>>> xwiki document source code from a selection on XHTML. >>>>>> >>>>>> This requires to have a correspondence between content >>>>>> typed by user and content that appears in html. >>>>>> >>>>>> I noticed in xwiki 2.0 synthax that white spaces typed >>>>>> in a list item context are ignored : >>>>>> >>>>>> *< >>>>>> space >>>>>>> >>>>>> < >>>>>> space >>>>>>> < >>>>>>> space >>>>>>>> < >>>>>>>> space><space>foo<space><space><space>bar<space><space><space> >>>>>> >>>>>> renders in XHTML >>>>>> >>>>>> <li>foo<space>&nbsp;&nbsp;bar&nbsp;&nbsp;&nbsp;</li> >>>>>> >>>>>> so I could not determine the real offset of selection in xwiki >>>>>> document source. >>>>> >>>>> There's another problem: leading spaces before list items and >>>>> headers. >>>>> We need to allow them (for several reasons, one of them is for >>>>> supporting indenting velocity code when we have velocity mixed >>>>> with >>>>> wiki syntax). So in term of rendering they should be considered >>>>> as a >>>>> ListItemBlock and the spaces should not be rendered. >>>>> >>>>> One problem is when we go through the wysiwyg these spaces >>>>> will be >>>>> removed. Removing them for content not in macros is not such a >>>>> big >>>>> deal IMO (except for Lucien's use case but there are other >>>>> ways of >>>>> doing it for him). Removing them would be a problem when inside >>>>> macros. Fortunately we don't touch at macro content for the >>>>> moment. >>>>> >>>>>> This can be solved by not ignoring spaces so render become : >>>>>> >>>>>> < >>>>>> li >>>>>>> >>>>>> &nbsp >>>>>> ;&nbsp >>>>>> ;&nbsp >>>>>> ;&nbsp;&nbsp;foo<space>&nbsp;&nbsp;bar&nbsp;&nbsp;&nbsp;</ >>>>>> li> >>>>>> >>>>>> This policy of rendering already exists in underline or italic >>>>>> context so it's strange to have a different behaviour in list >>>>>> item context. >>>>>> >>>>>> Moreover I think we should not suppose what content is >>>>>> relevant for user or not, so source shouldn't be altered. >>>>> >>>>> We have to alter source in the case of badly formed content, >>>>> as in >>>>> "**bold". We also later for unisignificant escapes (as with >>>>> "~hello"' >>>>> is transformed into "hello") + some other use cases probably. >>>>> >>>>> Right now I don't have any idea of what to do differently. Only >>>>> idea I >>>>> could think of would be to have a parameter for list items and >>>>> headers, passing to them the number of leading spaces, tabs, etc >>>>> but I >>>>> don't like this too much. >>>>> >>>>> I think the idea of leaving the content intact is not correct >>>>> and >>>>> we >>>>> shouldn't expect that behavior for a wiki syntax. A wiki syntax >>>>> needs >>>>> to be as simple as possible for users to use. Allowing leading >>>>> spaces >>>>> go in that direction. OTOH I agree with Lucien that we've >>>>> decided >>>>> to >>>>> make spaces in paragraph significant so it's not fully >>>>> consistent. >>>>> >>>>> What do others think? >>>> >>>> I agree that it's not alway possible to respect the original >>>> source >>>> especially with useless escapes (~toto which become toto). >>>> >>>> Now in the case of list item content I think we should support it >>>> because it's exactly the same context that space in a paragraph >>>> and >>>> such so it have to behave the same way for consistency. >>>> >>>> So +1 to support spaces at beginning of list item. >>> >>> Could you explain what you mean by "support spaces at begining of >>> list >>> item"? >> >> Yes it's not very clear: +1 for not removing first spaces of list >> item >> content. In other words +1 for changing the current behavior. > > This is still not clear. > > If we don't remove leading spaces is it still a list item? > > And if it's still a list item how do we implement this since lists > are > block elements? > > And what about spaces after the first space after the list item > delimiters? > +1 for : <#LI: (<SPACE>)* ( ("*")+ (":" | ";")* | ( "1" | "*" )+ "." (":" | ";")* | (":" | ";")+ ) (<SPACE>)* >