[xwiki-devs] [GSOC] sample xwiki syntax coloring plugin commited to the sandbox
Hi fabio, I have made the necessary modifications to the sample plugin and committed to the sandbox as org.xwiki.eclipse.editor.I have only refactor the code . No additional functionality was added to the previous plugin I have send to you by mail I'll start looking at the vinsents parser as you requested. Is there any news from Venkatesh also cheers -- Malaka Ekanayake CSE UOM
On 18 juin 08, at 20:10, malaka ekanayake wrote:
Hi fabio,
I have made the necessary modifications to the sample plugin and committed to the sandbox as org.xwiki.eclipse.editor.I have only refactor the code . No additional functionality was added to the previous plugin I have send to you by mail
Cool.
I'll start looking at the vinsents parser as you requested.
Ok.
Is there any news from Venkatesh also
Venkatesh sent an email yesterday I think. Maybe it would be good that he merges his work in the sandbox so that we will have a single project to work on. WDYT? Cheers, Fabio
Hi fabio On Thu, Jun 19, 2008 at 1:04 PM, Fabio Mancinelli < [email protected]> wrote:
On 18 juin 08, at 20:10, malaka ekanayake wrote:
Hi fabio,
I have made the necessary modifications to the sample plugin and committed to the sandbox as org.xwiki.eclipse.editor.I have only refactor the code . No additional functionality was added to the previous plugin I have send to you by mail
Cool.
I'll start looking at the vinsents parser as you requested.
Ok.
Is there any news from Venkatesh also
Venkatesh sent an email yesterday I think. Maybe it would be good that he merges his work in the sandbox so that we will have a single project to work on.
It's sounds good.So I can also learn from his work also
WDYT?
Cheers, Fabio
By the way I have send a skype invitation to you.Have you got it ? -- Malaka Ekanayake CSE UOM
malaka ekanayake wrote:
Hi fabio
On Thu, Jun 19, 2008 at 1:04 PM, Fabio Mancinelli < [email protected]> wrote:
On 18 juin 08, at 20:10, malaka ekanayake wrote:
Hi fabio,
I have made the necessary modifications to the sample plugin and committed to the sandbox as org.xwiki.eclipse.editor.I have only refactor the code . No additional functionality was added to the previous plugin I have send to you by mail
Cool.
I'll start looking at the vinsents parser as you requested.
Ok.
Is there any news from Venkatesh also
Venkatesh sent an email yesterday I think. Maybe it would be good that he merges his work in the sandbox so that we will have a single project to work on.
It's sounds good.So I can also learn from his work also
WDYT?
Cheers, Fabio
By the way I have send a skype invitation to you.Have you got it ? -- Malaka Ekanayake CSE UOM _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
On Jun 19, 2008, at 10:09 AM, Venkatesh Nandakumar wrote: [snip]
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
Done. Thanks -Vincent
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 <[email protected]> wrote:
On Jun 19, 2008, at 10:09 AM, Venkatesh Nandakumar wrote:
[snip]
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
Done.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Fabio, Malaka, After my discussion with Stephane, we've decided that Malaka should continue with improving the core editor as such.. That is, better syntax highlighting and stuff.. I've implemented a bit of ContentOutline Page, (that shows the overall view of the page, like titles, paragraphs overview etc), as a TreeViewer implementation. For now, I'll try to integrate the present editor with xeclipse extension. Then, I'd try to introduce wikimodel support, that is, conversion of one syntax to another syntax. For this, I think we'll have to code editors for all other syntaxes too, since after conversion, we'll have to support editing in that syntax.. right?? Then I'll be doing more advanced content assist, proposal, i.e, give the user the list of pages that can be linked, as a contest assist proposal, using the rpc api of xwiki.. Cheers, Venkatesh On Thu, Jun 19, 2008 at 14:36, Venkatesh Nandakumar <[email protected]> wrote:
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 <[email protected]> wrote:
On Jun 19, 2008, at 10:09 AM, Venkatesh Nandakumar wrote:
[snip]
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
Done.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 24 juin 08, at 11:53, Venkatesh Nandakumar wrote:
Hi Fabio, Malaka,
After my discussion with Stephane, we've decided that Malaka should continue with improving the core editor as such.. That is, better syntax highlighting and stuff..
What do you refer to when you say "stuff"?
I've implemented a bit of ContentOutline Page, (that shows the overall view of the page, like titles, paragraphs overview etc), as a TreeViewer implementation.
For now, I'll try to integrate the present editor with xeclipse extension. Then, I'd try to introduce wikimodel support, that is, conversion of one syntax to another syntax. For this, I think we'll have to code editors for all other syntaxes too, since after conversion, we'll have to support editing in that syntax.. right??
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
Sir, Sorry for being vague in my previous mail. On Tue, Jun 24, 2008 at 14:32, Fabio Mancinelli <[email protected]> wrote:
On 24 juin 08, at 11:53, Venkatesh Nandakumar wrote:
Hi Fabio, Malaka,
After my discussion with Stephane, we've decided that Malaka should continue with improving the core editor as such.. That is, better syntax highlighting and stuff..
What do you refer to when you say "stuff"?
By 'stuff', I meant the following:- Syntax highlighting and coloring Content Assists, Quick Fixes & error marking.. Auto Edit Features & formatting support Context Information Double Click Strategies, Text Hover features, appropriate partitioning.. Except 'error marking' and quick fixes, as you would have seen from my code, I have implemented the other features to a large extent. Though, lot of work will have to be done to make it perfect, which is what I was hoping malaka would do.
I've implemented a bit of ContentOutline Page, (that shows the overall view of the page, like titles, paragraphs overview etc), as a TreeViewer implementation.
For now, I'll try to integrate the present editor with xeclipse extension. Then, I'd try to introduce wikimodel support, that is, conversion of one syntax to another syntax. For this, I think we'll have to code editors for all other syntaxes too, since after conversion, we'll have to support editing in that syntax.. right??
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?
Ok, then we will wait for his study of the parser. I just went over the parser, and kind of understood it, but i could understand where we could actually bring the two code to the same level, in other words, integrate it, cause the basic functioning of the TextEditor is based on set of 'Rules', quite unlike the parser.
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).
Well, I'll be working on the following points:- 1. Content Outline. ( Partially done with revision 208). 2. Integrating present XEclipse code 3. Wikimodel integration as mentioned above 4. Advanced-rpc based content assist. Now, since I've told about the respective portions we'll be individually working on, I think there would not be any overlapping again. Venkatesh
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jun 24, 2008, at 11:53 AM, Venkatesh Nandakumar wrote:
Hi Fabio, Malaka,
After my discussion with Stephane, we've decided that Malaka should continue with improving the core editor as such.. That is, better syntax highlighting and stuff..
I've implemented a bit of ContentOutline Page, (that shows the overall view of the page, like titles, paragraphs overview etc), as a TreeViewer implementation.
For now, I'll try to integrate the present editor with xeclipse extension. Then, I'd try to introduce wikimodel support, that is, conversion of one syntax to another syntax. For this, I think we'll have to code editors for all other syntaxes too, since after conversion, we'll have to support editing in that syntax.. right??
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
Then I'll be doing more advanced content assist, proposal, i.e, give the user the list of pages that can be linked, as a contest assist proposal, using the rpc api of xwiki..
Cheers, Venkatesh
On Thu, Jun 19, 2008 at 14:36, Venkatesh Nandakumar <[email protected]> wrote:
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 <[email protected]> wrote:
On Jun 19, 2008, at 10:09 AM, Venkatesh Nandakumar wrote:
[snip]
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
Done.
Thanks -Vincent
On Jun 24, 2008, at 8:20 PM, Vincent Massol wrote:
On Jun 24, 2008, at 11:53 AM, Venkatesh Nandakumar wrote:
Hi Fabio, Malaka,
After my discussion with Stephane, we've decided that Malaka should continue with improving the core editor as such.. That is, better syntax highlighting and stuff..
I've implemented a bit of ContentOutline Page, (that shows the overall view of the page, like titles, paragraphs overview etc), as a TreeViewer implementation.
For now, I'll try to integrate the present editor with xeclipse extension. Then, I'd try to introduce wikimodel support, that is, conversion of one syntax to another syntax. For this, I think we'll have to code editors for all other syntaxes too, since after conversion, we'll have to support editing in that syntax.. right??
No please don't do this! This is exactly what I have written in the new rendering module.
Just to be clear I was referring of converting syntaxes. Thanks -Vincent
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
Then I'll be doing more advanced content assist, proposal, i.e, give the user the list of pages that can be linked, as a contest assist proposal, using the rpc api of xwiki..
Cheers, Venkatesh
On Thu, Jun 19, 2008 at 14:36, Venkatesh Nandakumar <[email protected]> wrote:
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 <[email protected]> wrote:
On Jun 19, 2008, at 10:09 AM, Venkatesh Nandakumar wrote:
[snip]
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
Done.
Hi all see my comments below On Tue, Jun 24, 2008 at 11:50 PM, Vincent Massol <[email protected]> wrote:
On Jun 24, 2008, at 11:53 AM, Venkatesh Nandakumar wrote:
Hi Fabio, Malaka,
After my discussion with Stephane, we've decided that Malaka should continue with improving the core editor as such.. That is, better syntax highlighting and stuff..
I've implemented a bit of ContentOutline Page, (that shows the overall view of the page, like titles, paragraphs overview etc), as a TreeViewer implementation.
For now, I'll try to integrate the present editor with xeclipse extension. Then, I'd try to introduce wikimodel support, that is, conversion of one syntax to another syntax. For this, I think we'll have to code editors for all other syntaxes too, since after conversion, we'll have to support editing in that syntax.. right??
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.
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
Also I'd like to know if the new rendering API is missing anything you'd need for your use cass.
Thanks -Vincent
Then I'll be doing more advanced content assist, proposal, i.e, give the user the list of pages that can be linked, as a contest assist proposal, using the rpc api of xwiki..
Cheers, Venkatesh
On Thu, Jun 19, 2008 at 14:36, Venkatesh Nandakumar <[email protected]> wrote:
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 <[email protected]> wrote:
On Jun 19, 2008, at 10:09 AM, Venkatesh Nandakumar wrote:
[snip]
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
Done.
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Thanks -- Malaka Ekanayake CSE UOM
Hi Malaka, On Jun 24, 2008, at 10:41 PM, malaka ekanayake wrote:
Hi all
see my comments below
On Tue, Jun 24, 2008 at 11:50 PM, Vincent Massol <[email protected]> wrote:
On Jun 24, 2008, at 11:53 AM, Venkatesh Nandakumar wrote:
Hi Fabio, Malaka,
After my discussion with Stephane, we've decided that Malaka should continue with improving the core editor as such.. That is, better syntax highlighting and stuff..
I've implemented a bit of ContentOutline Page, (that shows the overall view of the page, like titles, paragraphs overview etc), as a TreeViewer implementation.
For now, I'll try to integrate the present editor with xeclipse extension. Then, I'd try to introduce wikimodel support, that is, conversion of one syntax to another syntax. For this, I think we'll have to code editors for all other syntaxes too, since after conversion, we'll have to support editing in that syntax.. right??
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.
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
Sounds good. I've skimmed very quickly through http://www.realsolve.co.uk/site/tech/jface-text.php and this is my understanding too. Some open questions/remarks/ comments I have: * What I'm not sure yet (since I haven't read that far ;)) is how you plug the IDocumentPartitioner to the syntax highlighting. * XDOM is a tree, i.e. Blocks are nested. Are the partitions nested too? * Re the offset and lengthn I think this is something interesting that could be added to the new rendering module. Since the underlying parsers (wikimodel, doxia) don't pass this information to us we would need to compute it. It would allow us to answer the question "what block is located at location NN in the source document". * We need to get Marius' input since he's working on the new WYSIWYG editor for XWiki and maybe he has some similar needs/issues. Also I see that JFace has lots of existing rule-based APIs to simply parsing/scanning (a la http://jparsec.codehaus.org/) so I'm still unsure if we can plug the rendering parser in a natural manner. I don't know JFace at all so some advice from someone who knows it would be nice. Thanks -Vincent
Also I'd like to know if the new rendering API is missing anything you'd need for your use cass.
Thanks -Vincent
Then I'll be doing more advanced content assist, proposal, i.e, give the user the list of pages that can be linked, as a contest assist proposal, using the rpc api of xwiki..
Cheers, Venkatesh
On Thu, Jun 19, 2008 at 14:36, Venkatesh Nandakumar <[email protected]> wrote:
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 <[email protected]> wrote:
On Jun 19, 2008, at 10:09 AM, Venkatesh Nandakumar wrote:
[snip]
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
Done.
Thanks -Vincent
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 <[email protected]> wrote:
Hi Malaka,
On Jun 24, 2008, at 10:41 PM, malaka ekanayake wrote:
Hi all
see my comments below
On Tue, Jun 24, 2008 at 11:50 PM, Vincent Massol <[email protected]> wrote:
On Jun 24, 2008, at 11:53 AM, Venkatesh Nandakumar wrote:
Hi Fabio, Malaka,
After my discussion with Stephane, we've decided that Malaka should continue with improving the core editor as such.. That is, better syntax highlighting and stuff..
I've implemented a bit of ContentOutline Page, (that shows the overall view of the page, like titles, paragraphs overview etc), as a TreeViewer implementation.
For now, I'll try to integrate the present editor with xeclipse extension. Then, I'd try to introduce wikimodel support, that is, conversion of one syntax to another syntax. For this, I think we'll have to code editors for all other syntaxes too, since after conversion, we'll have to support editing in that syntax.. right??
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.
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
Sounds good. I've skimmed very quickly through http://www.realsolve.co.uk/site/tech/jface-text.php and this is my understanding too. Some open questions/remarks/ comments I have:
* What I'm not sure yet (since I haven't read that far ;)) is how you plug the IDocumentPartitioner to the syntax highlighting. * XDOM is a tree, i.e. Blocks are nested. Are the partitions nested too? * Re the offset and lengthn I think this is something interesting that could be added to the new rendering module. Since the underlying parsers (wikimodel, doxia) don't pass this information to us we would need to compute it. It would allow us to answer the question "what block is located at location NN in the source document". * We need to get Marius' input since he's working on the new WYSIWYG editor for XWiki and maybe he has some similar needs/issues.
Also I see that JFace has lots of existing rule-based APIs to simply parsing/scanning (a la http://jparsec.codehaus.org/) so I'm still unsure if we can plug the rendering parser in a natural manner.
I don't know JFace at all so some advice from someone who knows it would be nice.
Thanks -Vincent
Also I'd like to know if the new rendering API is missing anything you'd need for your use cass.
Thanks -Vincent
Then I'll be doing more advanced content assist, proposal, i.e, give the user the list of pages that can be linked, as a contest assist proposal, using the rpc api of xwiki..
Cheers, Venkatesh
On Thu, Jun 19, 2008 at 14:36, Venkatesh Nandakumar <[email protected]> wrote:
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 <[email protected]> wrote:
On Jun 19, 2008, at 10:09 AM, Venkatesh Nandakumar wrote:
[snip]
> 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
Done.
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Malaka Ekanayake CSE UOM
On 25 juin 08, at 05:57, malaka ekanayake wrote:
*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 ?
Hi Malaka, have you already setup a simple source code that bootstraps the XWiki parsing infrastructure and builds an XDOM from an XWiki document? I haven't had the time to play with it so if you have it, could you commit it to the sandbox in a 'xdom' package of your plugin? In this way we can have a look and work together in order to an xdom-based IDocumentPartitioner, taking also into account Sergiu's suggestions. Let me know. Cheers, Fabio
On 24 juin 08, at 23:07, Vincent Massol wrote:
Sounds good. I've skimmed very quickly through http://www.realsolve.co.uk/site/tech/jface-text.php and this is my understanding too. Some open questions/remarks/ comments I have:
I agree as well.
* What I'm not sure yet (since I haven't read that far ;)) is how you plug the IDocumentPartitioner to the syntax highlighting.
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).
* XDOM is a tree, i.e. Blocks are nested. Are the partitions nested too?
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.
Also I see that JFace has lots of existing rule-based APIs to simply parsing/scanning (a la http://jparsec.codehaus.org/) so I'm still unsure if we can plug the rendering parser in a natural manner.
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
Fabio Mancinelli wrote:
On 24 juin 08, at 23:07, Vincent Massol wrote:
Sounds good. I've skimmed very quickly through http://www.realsolve.co.uk/site/tech/jface-text.php and this is my understanding too. Some open questions/remarks/ comments I have:
I agree as well.
* What I'm not sure yet (since I haven't read that far ;)) is how you plug the IDocumentPartitioner to the syntax highlighting.
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).
* XDOM is a tree, i.e. Blocks are nested. Are the partitions nested too?
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 don't know anything about JFace, so sorry if I'm completely off course. Can blocks have arbitrary attributes? One way to embed trees into partitions is to add an attribute on all the leaves under a given node. For example: * this is a list * this is a *text with __markup__*. could become, as a tree: - list |- list item | |- text: this is a list |- list item | |- text: this is a | |- bold | | |- text: text with | | |- underline | | | |- text: markup | |- text: . which in turn becomes a partition like: (list item) this is a list (list item separator)\n (list item) this is a (list item, bold) text with (list item, bold, underline) markup (list item) . To recompose a tree from partitions, start a new node whenever a new attribute is added, and end the node when that attribute disappears. Care must be taken to put breaking blocks between adjacent individual nodes of the same type, like the (list item separator) above.
Also I see that JFace has lots of existing rule-based APIs to simply parsing/scanning (a la http://jparsec.codehaus.org/) so I'm still unsure if we can plug the rendering parser in a natural manner.
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.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On 24 juin 08, at 22:41, malaka ekanayake 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.
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
participants (5)
-
Fabio Mancinelli -
malaka ekanayake -
Sergiu Dumitriu -
Venkatesh Nandakumar -
Vincent Massol