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/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
