[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [jdt-core-dev] JDT/Core needs you
|
Sounds appealing. Our current implementation also deals with a stream of
tokens, but hardcoding the formatting rules, instead of using a more
generic pattern matching approach.
One alternative we were considering was to simply parse the source and
pretty print it using some source template.
The point about comments amongst other tokens is indeed troublesome. Our
scanner can tokenize them, but they can show up in the middle of anything.
Furthermore, line splitting is also quite complicating the overall problem.
"Dave Wathen"
<dave.wathen@canzon To: <jdt-core-dev@xxxxxxxxxxx>
et.com> cc:
Sent by: Subject: RE: [jdt-core-dev] JDT/Core needs you
jdt-core-dev-admin@
eclipse.org
07/04/2002 11:36 AM
Please respond to
jdt-core-dev
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
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev