On Jun 12, 2008, at 9:58 AM, Fabio Mancinelli wrote: > > On 12 juin 08, at 08:01, Vincent Massol wrote: > >> Hi Malaka, >> >> Don't you need a xwiki syntax parser for this? >> >> As you probably know I have written such a parser in the new >> rendering module. Just make you don't reinvent one. >> >> Thanks >> -Vincent >> >> On Jun 12, 2008, at 6:05 AM, malaka ekanayake wrote: >> >>> Hi fabio >>> Regarding the xwiki syntax I have some questions. Up to now its >>> straightforward to implement the highlighting for syntaxes like >>> *bold*. >>> *bold* can be easily identified by a "MultiLineRule" as a single >>> partition. >>> But it is possible for someone to write a *bold~~bold >>> &italics~~bold*.Right ?. >>> So this can go on and on.How should I tackle this problem. >>> I think *bold~~bold &italics~~bold* should generate 3 partitions >>> because partitions are non overlapping. >>> *bold >>> ~~bold &italics~~ >>> bold* >>> Is this right ?. >>> Should I look into this problem later and implement the sample >>> plugin >>> for simple syntaxes like *bild*,~~italics~~ or not ? . >>> > > Hi all, > > Yes. By definition a partition is not overlapping, so if styles can > be composed generating a "compound style" such as bold-italic, this > should be in the context of a new partition type. > > For the parser Vincent has mentioned... It would be good to use it > as the "foundation".
To use it: * Use the component manager to look up the parser: role = org.xwiki.rendering.Parser, hint = xwiki/2.0 (that's xwiki 2.0 syntax btw but that's going to be the new syntax real soon and is very similar to the 1.0 syntax - main change are the macros). * Call parser.parse(String contentToParse). You get back a XDOM object which is an in memory DOM of the parsed content which contains Block (see org.xwiki.rendering.block package). Thanks -Vincent > > The idea is to use this parser as the "partitioner" where partitions > are the terminal symbols of the underlying grammar. > However, I guess we should check the compatibility of the Eclipse- > way of doing such a kind of things (that seems to me more regex- > oriented) vs the classical way using a lexer-parser. > > You might explore a little bit this solution, looking at Vincent's > parser. > > I avail myself of this mail for saying that there is an intern at > XWiki, Venkatesh Nandakumar, that is working on a XWiki semantic > editor, that apparently has some overlap with your work. Venkatesh > has already written some Eclipse-oriented syntax-highlighting code. > > Since I am not aware of what has been done, Venkatesh should present > what he did to the list, so that we can minimize the efforts and > avoid duplicate work. > > For what concerns your work, I suggest the following steps: > > 1) Try to finish a first version of the plugin with "compound style" > partitioning. This is good for gaining a better understanding of the > Eclipse text framework. > > 2) Take a look at Vincent's parser and try to understand if it's > easy/feasible to use it as the partion-source (I'll look at this > issue as well). > > 3) Wait for Venkatesh to tell us what he has done so that we can all > synchronize. > > Cheers, > Fabio _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
