RE: [jdt-core-dev] JDT/Core needs you

["Dave Wathen" <dave.wathen@xxxxxxxxxxxx>]

In response to the appeal for contributions, I'd like to offer some
thoughts on the subject of code formatting.  If people like the proposed
approach I'd be happy to develop the software to implement it (any help
gratefully received).

All the current approaches to formatting (that I've seen) are configured
by giving the user choices on how to handle certain predefined situations.
This approach will always limit the functionality of the formatter to the
set of situations and choices that the formatter has been coded to support.

The alternative I'd like to propose is that of a formatter which is
configurable by describing conditions and the formatting that should be
applied under those conditions.

In order to specify the conditions, the formatter would view the source
as a token stream.  A form of regular expression would be used to describe
token patterns.  The configuration of the formatter would consist of a
set of rules where each rule consisted of:

- a regular expression to denote when it applies
- a formatting specification to describe how to format the matched tokens

A formatting specification would consist of a sequence of instructions to
a source code writer.  The instructions would be things like:

- ensure n blank lines
- insert soft spaces (spaces omitted at start/end of line)
- start an indentation
- end an indentation
- print a token
- establish a wrap point
- apply rules to a subsequence of the matched tokens

Further I would envision the writer would work in a transactional manner
so that it would be possible to apply formatting instructions and then
back them out.  This would allow for multiple line-breaking strategies
to be specified.  Each could be tried until a satisfactory result was
achieved and the transaction would then be committed.  Nesting of
transactions
would be necessary to support subsequence rule evaluation.

Points that require further thought:

- How to handle comments as part of the token stream
- Does the transactional nature of the writer impose too great
  a memory penalty
- What would be the best way of presenting this functionality
  to its users.  Possibly a layered approach where raw
  configuration is as described and higher-level models build
  on it to offer simple formatting choices as in existing
  formatters.
- How could this best be integrated with the existing JDT core.

Well that's about as far as I've thought things through so far.  In the
interests
of clarity I'd like to mention my situation.  I'm a contractor so my time
and
availability can vary substantially.  If people would like me to progress
this,
I'll put in as much effort as I'm able to but I can't offer any guarantees.

Dave Wathen
Canzonet Limited
Phone: 020 8660 5171
Mobile: 07968 167934
http://www.canzonet.com
mailto:dave.wathen@xxxxxxxxxxxx

-----Original Message-----
From: jdt-core-dev-admin@xxxxxxxxxxx
[mailto:jdt-core-dev-admin@xxxxxxxxxxx]On Behalf Of Philippe Mulet
Sent: 03 July 2002 16:08
To: jdt-core-dev@xxxxxxxxxxx
Subject: [jdt-core-dev] JDT/Core needs you


We are always looking for external contributors on various front. Now that
the release 2.0 is out, is a good time to candidate...

Help would be welcome on various front, from documentation, test suites to
active development on various fronts.
We are looking at rewriting our indexing infrastructure, our source code
formatter, in addition to augmenting the Java Model with ways to batch
operations.
We are also going to investigate support for generics, better codeassist
(relevance mechanism) etc...

Our bug database also contains suggestions for improvement (look at PR
which status is LATER)
http://dev.eclipse.org/bugs/buglist.cgi?resolution=LATER&product=JDT&compone
nt=Core

So feel free to jump in the JDT/Core effort.

- The JDT/Core team

_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev