[news.eclipse.tools] Re: JavaEditor slowdown: RuleBasedPartitioner scans

["Kai-Uwe Maetzel" <kai-uwe_maetzel@xxxxxxx>]

The decision what partitioning is useful depends on
the structural semantics of the text your editor is thought for.
For example, editing java doc and regular java code differ
among others in:
- the selection set on double click (java code selection
  differs from, e.g., Hebrew java doc selection)
- content assist behavior
- auto indent behavior
As the text viewer allows to configure this behavior depending
on partition types, a java document is partitioned accordingly.

In addition, every multi-line token which is relevant for syntax
highlighting should be represented as partition.

When building a custom editor  you might think along
those lines. You might also consider building your own
custom made document partitioner rather than using the
rule based one.

Kai


"David Sanders" <dsanders@xxxxxxxxxxx> wrote in message
news:3BA0EE07.86E69EC6@xxxxxxxxxxxxxx
> Yes, and editing a large Java file containing few multi-line comments and
no
> JavaDoc comments is very slow under the current scheme.  Should I create
> arbitrary partitions for my custom editor in order to allow the user to
type
> fast and still have keyword highlighting?  Also, how does one decide what
a
> good candidate for a partition is?
>
> David
>
>
> Kai-Uwe Maetzel wrote:
>
> > By default case I guess you mean that the document does
> > not contain any other partition than one partition of type
> > IDocument.DEFAULT_CONTENT_TYPE.
> >
> > Given the current partitioning scheme of the java editor, this
> > is the case if the java code to be presented does not contain
> > any multi-line comment, i.e. a comment delimited by "/*" and "*/".
> >
> > The RuleBasedPartitioner does only stop at sustained partition
> > boundaries to cover the family of case in which delimited
> > tokens can mask each other:
> >
> > Assume the case that the string "/ " is somewhere in the java code.
> > Further assume that inside java strings "/*" and "*/" appear several
> > times and that the java code does not contain any multi-line comment.
> > As the comment delimiters are inside strings, they don't affect the
> > partitioning. If now the space in "/ " is replaced with a '*' a
multi-line
> > comment starts there terminated by a delimiter previously found in a
> > string. Depending on the actual number of strings in the java code
> > everything that previously has been inside a string is now outside and
> > the other way around. Thus, the document changes from being not
> > partitioned to be partitioned.
> >
> > Kai
> >
> > "David Sanders" <dsanders@xxxxxxxxxxx> wrote in message
> > news:3B9FB109.FFA2113@xxxxxxxxxxxxxx
> > > For each keypress, the RuleBasedPartitioner's documentChanged(...)
> > > method rescans the entire document in the default case, regardless of
> > > which part of the document has changed.  This leads to a slowdown in
the
> > > Java Editor, etc.
> > >
> > > (Eclipse R0.9 B0.125)
> > >
> > > David
> > >
>