View previous topic :: View next topic |
Author |
Message |
asterite
Joined: 01 Jun 2006 Posts: 235 Location: Buenos Aires, Argentina
|
Posted: Mon Jan 08, 2007 3:38 pm Post subject: Project Plan |
|
|
Well, I'll describe not so breifly the plan for the whole project.
I'll start with what I'd like to see in the plugin, from easy to hard:
1. Compile.
2. Basic syntax coloring: keywords, strings, comments, etc.
3. Templates: write "if" and ctrl + space gives a choice to complete the whole sentence "if (|) { }", etc.
4. Utilities: for example, if you write " in JDT, the closing " is automatically added (and it enters linked mode edition). Same goes with {. Etc.
5. Execute programs within Eclipse.
6. Point out compile errors as "error on line 1"
7. Outline view.
8. Advanced syntax coloring: types, functions, local and member variables, etc.
9. Autocomplete (aka intellisense).
10. Types and functions search (similar to Ctrl + T in JDT).
11. Goto definition (similar to F3 or ctrl + click in JDT).
12. Advanced utilities like the ones in JDT: extract to local variable, organize imports, etc.
13. Documentation on hover.
14. Point out compile errors in specific tokens or source ranges (like JDT). Not just syntax error, but semantic errors.
15. Preferences for some of the above points.
16. --- Enter your comment here ---
Point 1 is fundamental. Without it the user would go to a command line or rely on some utility to compile. The intention of the plugin is to leave the editor as least as possible. Point 5 is also important for the same reason.
With that two points, plus maybe basic syntax coloring (which is sort of done), the plugin is useful. From that moment releases could be made when something new and good is done.
The other points make development easier and faster. This is also important but not fundamental. Also, the other points are a lot harder. From what I've seen in JDT, to get the most from the plugin we'll need:
- to build an AST tree ( check org.eclipse.jdt.core.dom.ASTNode )
- to build an ASTRewrite ( check org.eclipse.jdt.core.dom.ASTRewrite)
- to build an overview model of all the D projects in the workspace ( check org.eclipse.jdt.IJavaElement )
- to make a search engine ( check org.eclipse.jdt.search )
- to make some kind of visitor to proccess the semantic of the tree to get point 14
- some other hard work
This is a LOT of work. This will take months. I can copy JDT, but just copying isn't going to work, because core changes must be done (the model isn't the same).
What is already done:
- the syntax coloring is done, except that it isn't configurable.
- the AST tree is pretty finished.
- all syntax errors are captured.
- I've copied a lot of classes from org.eclipse.jdt.core (internal, dom, search), but none of these is useful yet since the model is the one from Java, not from D.
So I suggest keeping the current code away, in a different branch, and transforming the trunk to have points 1, 2, 3, 4, 5, 6 and 15. This is useful, believe it or not. Especially if autobuild is enabled for a project (compile on save). The plugin can obtain compile errors by parsing the underlying compiler's output (easy).
What do you think?
One last question: what do you think about pointing out semantic compile errors? I think it's not that hard: they are in in DMD source's code. Of course the underlying compiler will redo that work sooner or later, but for the user it's awsome to see errors quickly, as he types. |
|
Back to top |
|
|
keinfarbton
Joined: 03 Dec 2005 Posts: 224 Location: Stuttgart - Germany
|
Posted: Mon Jan 08, 2007 7:05 pm Post subject: |
|
|
If I reorder your list to my personal priorities:
--- M1 ---
1. Compile.
6. Point out compile errors as "error on line 1" (jump to position)
15. Preferences for some of the above points.
(2. Basic syntax coloring: keywords, strings, comments, etc.)
+ show syntax errors while writing.
+ project preferences*
--- M2 ---
9. Autocomplete (aka intellisense).
10. Types and functions search (similar to Ctrl + T in JDT).
11. Goto definition (similar to F3 or ctrl + click in JDT).
--- M3 ---
5. Execute programs within Eclipse.
Project preferences:
Define libs, include paths, special build options, ...
Have muliple build targets in one project.
Semantic errors are low priority for me, because we have that with each compiler run. |
|
Back to top |
|
|
qbert
Joined: 30 Mar 2004 Posts: 209 Location: Dallas, Texas
|
Posted: Wed Jan 10, 2007 3:44 pm Post subject: |
|
|
keinfarbton wrote: | If I reorder your list to my personal priorities:
Project preferences:
Define libs, include paths, special build options, ...
Have muliple build targets in one project.
Semantic errors are low priority for me, because we have that with each compiler run. |
Arent libs , include paths and any special options defined by Ant ?
Is there going to be more builder support for this plugin besides Ant ? |
|
Back to top |
|
|
keinfarbton
Joined: 03 Dec 2005 Posts: 224 Location: Stuttgart - Germany
|
Posted: Wed Jan 10, 2007 4:45 pm Post subject: |
|
|
I though about doing workbench preferences to configure the installed compiler with there type (dmd/gdc) and language version.
The project shall be configured to build multiple targets. Each with a certain set of build switches, compiler, ....
The user selects the target, he is working on. The plugin parser rescans the sources with these version/debug flags. Running a build will generate a ANT build.xml and starts ANT. The user shall have the possibiliy to include an own build.xml. Also it shall be possible to run ANT standalone. |
|
Back to top |
|
|
qbert
Joined: 30 Mar 2004 Posts: 209 Location: Dallas, Texas
|
Posted: Wed Jan 10, 2007 7:42 pm Post subject: |
|
|
That sounds great, and alot easier for the user. Did you check in those preference pages ? |
|
Back to top |
|
|
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Mon May 21, 2007 6:09 pm Post subject: |
|
|
--- Enter your comment here ---
How about an option to highlight all instances of the current token under the cursor, like in JDT? It makes a manual find and replace much easier. |
|
Back to top |
|
|
asterite
Joined: 01 Jun 2006 Posts: 235 Location: Buenos Aires, Argentina
|
Posted: Mon May 21, 2007 6:38 pm Post subject: |
|
|
JoeCoder wrote: | --- Enter your comment here ---
How about an option to highlight all instances of the current token under the cursor, like in JDT? It makes a manual find and replace much easier. |
It'll surely be in a future, but to do that the plugin must know which are all the references to that variable. It's not just highlighting the ocurrences of the token under the cursor: that sure is easy to do, but not very useful.
To do the above, the plugin must first analyze the code... porting DMD's semantic analysis is an ongoing work, but it's a long process... In the meantime we are also doing some other stuff: making the plugin to actually compile things (not to depend on an external tool), enhancing the debugger interface, implementing formatting stuff...
Thanks for your suggestion! |
|
Back to top |
|
|
alyan
Joined: 10 Jul 2007 Posts: 7
|
Posted: Thu Jul 19, 2007 10:48 pm Post subject: |
|
|
I think you should add syntax highlighting to ddoc keywords, such as Authors:, Params: and stuff like that. It's relatively simple to do it, and would be really helpful.
And I agree with the DMD 2.0 dude, those red underlines are annoying, 2.0 version support would be cool... xD
Best regards,
Daniel |
|
Back to top |
|
|
fraserofthenight
Joined: 08 Apr 2007 Posts: 33 Location: Seattle, WA
|
Posted: Tue Jul 24, 2007 10:29 pm Post subject: |
|
|
In the next release. In fact, there'll be a whole DDoc viewer so you can see the generated HTML (complete with macro replacement) as you type. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|