[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [jdt-core-dev] JDT/Core needs you
|
Given that the existing formatter works off tokens and does line-number
mapping it sounds like a good basis for the proposed formatter.
I should have some time next week I'll take a look at the current
implementation and see if I can put together a prototype of the proposed
solution based on it. Unless, of course, there's a good reason to hold
off for now.
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: 04 July 2002 23:05
To: jdt-core-dev@xxxxxxxxxxx
Subject: RE: [jdt-core-dev] JDT/Core needs you
If we have a good formatter, then what Dani suggests is purely UI work. An
editor might offer to present source reformatted on the fly, but I agree
with you that it would make no sense if modifying the source, since it
would only create more outgoing changes for free.
When developping concurrently, format changes are just killing your
teammates who want to reconcile *real* changes with you...
But anyway, one good point is that the new code formatter should also be
able to map line positions (before->after formatting) so as to ease the
process of moving marker annotations (the current implementation does it
already).
"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 04:12 PM
Please respond to
jdt-core-dev
If you want to allow this it could be handled by having named
configurations of the formatter rules. You could then apply
one set of rules to get your personal preferences as you obtain
stuff from the team repository and another set to return it to
the standard when you check stuff back in.
Since you wouldn't be seeing the code in the format you are
submitting it you'd have to have a very high level of confidence
in the formatter.
I wonder about the wisdom of this though. Developers will need to
use the standard format too anyway. Bug reports (stack traces) would
be reported against the standard version assuming the main build
runs off the repository. Similarly communication between developers
could get confused.
Perhaps the multi-configuration idea is good but not the automatic
conversion at check in/out. This would allow a developer to use his
own preferences whilst doing large-scale development work and push it
back to the standard before he completes and re-checks in.
Yet another option would be to have the two configurations of the
formatter run concurrently so that the editor allows two representations
of the code to be seen simultaneously with the standard version being
the canonical one that got compiled etc. Line number conversion between
the two could then let the developer see (for example) the compiler
errors from the standard format reported against their own preferred
format.
Sorry this has been a bit rambling - just thinking out loud really.
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 Daniel Megert
Sent: 04 July 2002 14:39
To: jdt-core-dev@xxxxxxxxxxx
Subject: RE: [jdt-core-dev] JDT/Core needs you
An interesting problem with formatting is also that a team (or project)
normally wants its source in a well defined format while programmer X would
like to look at the source in his preferred way. Currently all users of a
team have to obey i.e. use the team's/project's formatting rules.
Dani
|---------+------------------------------>
| | "Philippe Mulet" |
| | <Philippe_Mulet@oti|
| | .com> |
| | Sent by: |
| | jdt-core-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 07/04/2002 02:54 PM|
| | Please respond to |
| | jdt-core-dev |
| | |
|---------+------------------------------>
>
---------------------------------------------------------------------------
----------------------------------------------------|
|
|
| To: jdt-core-dev@xxxxxxxxxxx
|
| cc:
|
| Subject: 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
_______________________________________________
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
_______________________________________________
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
