25 Jun
2008
25 Jun
'08
11:29 a.m.
Fabio Mancinelli wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On 24 juin 08, at 23:07, Vincent Massol wrote:
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.
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.