malaka ekanayake wrote: Hi, I just saw Malaka's code now. I'm actually merging my code to his now, seems I don't have the committing rights to sandbox as of yet. Mr Vincent, please give the appropriate rights to my id vnkatesh Thanking you, Venkatesh N

Hi, I've uploaded my project to http://svn.xwiki.org/svnroot/sandbox/org.xwiki.eclipse.plugin/ , please go through the Sample.xwiki file. Malaka can go through the code, and implement the extra features to this. Cheers, Venkatesh On Thu, Jun 19, 2008 at 10:34, Vincent Massol <vincent(a)massol.net> wrote:

On 24 juin 08, at 11:53, Venkatesh Nandakumar wrote: What do you refer to when you say "stuff"? Actually this is exactly what the GSoc project is about (not just plain syntax highlighting). So this might be an issue because this is exactly what Malaka is supposed to do. Currently he is investigating the integration of the new rendering infrastructure into the Eclipse framework so that the output XDOM will be the base for all the syntax highlighting, suggestions etc. Malaka, could you please report the status of your investigation and the problems you encountered? I still have the feeling that you are both working on the very same project, with a big overlap (i.e., the "stuff" you mentioned before that should be done by Malaka is exactly what you are working on). I propose that Malaka continues to work on the integration of the rendering infrastructure as the source of structural information, exchanging as much as possible on the list. If he succeeds this means that your code will need to be refactored to conform to the new architecture. If he doesn't then he will improve what you have been doing. I don't see any other solution to reconcile your work with the GSoC. WDYT? Cheers, Fabio

On Jun 24, 2008, at 11:53 AM, Venkatesh Nandakumar wrote: No please don't do this! This is exactly what I have written in the new rendering module. I'd like that both Malaka and you spend some time understanding the new rendering module. Please ask as many questions as you want here since it's not currently well documented but please don't reinvent the wheel. Also I'd like to know if the new rendering API is missing anything you'd need for your use cass. Thanks -Vincent

Hi all see my comments below On Tue, Jun 24, 2008 at 11:50 PM, Vincent Massol <vincent(a)massol.net> wrote: I have looked at the parser and rendering api. I think we can integrate with the jface editor in the following way We can extract blocks from the XDOM object created by the parser.Then if we can find a way to map these blocks with non overlapping partitions defined in the jface,then it seems like we can integrate both.As I have realised partitions need the offset and the length with respect to the xwiki document.I think we need to add 2 methods to the Block inteface to get the offset and the length. According to my current undestanding we need to impliment the IDocumentPartitioner inteface and use the excisting xwiki parser in thet implimentation.The main perpose of the implimentation is to map the blocks in to partitions. please give your comments on this Thanks -- Malaka Ekanayake CSE UOM

hi Vincent/Fabio, *According to my knowledge partitions should not be overlap.But the XDOM model is nested. I think that might be a problem. The sample plugin I have made is also base on partitioning the entire document to non overlapping reagents so each partition can be then subjected to syntax coloring. *I tried to use the existing api(rule bale partitions) to nested syntax as well .But it turned out difficile *I need help on this. *WDUT ? Thanks -Malaka On Wed, Jun 25, 2008 at 2:37 AM, Vincent Massol <vincent(a)massol.net> wrote: -- Malaka Ekanayake CSE UOM

On 24 juin 08, at 23:07, Vincent Massol wrote: I agree as well. Once you have a partitioning which basically assign to every disjoint portion of the document a type, you can assign them a scanner which further divide the partition's content into tokens and assign to them display attributes, or you can attach to a partition type a given content assistant which provides suggestions for that context. An engineering effort should be made to decide where the partitioning ends and where, for example, the scanner starts. As a degenerate case we could consider the document as a single huge partition, and write a scanner that identifies elements into this huge partition. While this could work fine for syntax highlighting, it is completely useless for content assistance (what would be a suggestion for a whole document? We need suggestions for links, macros... This should guide the engineering of the relevant partition types that can be useful to consider). No, by definition partitions are disjoint. What I think should be done is to clearly identify what are the XDOM blocks that we want to consider partitions. I think that considering XDOM tree leaves as partitions could be fine. I think that as a first approximation, we can parse the whole document and, by having in mind which XDOM blocks are the partitions for us, we can return them using JFace mechanisms. This means that we need to write a complete implementation of the IDocumentPartitioner and probably we will not be able to use the general purpose rules and partitioners already defined in the framework. WDYT? Cheers, Fabio

On 24 juin 08, at 22:41, malaka ekanayake wrote: I think you are right. I didn't look in detail into this, but we could start by making every leaf of the XDOM tree as a different partition. Cheers, Fabio