TWiki > Dev > EclipsePlugin (r1.34)	TWiki webs: Dev | Doc | Main | TWiki | Sandbox
	Dev . { Changes | Index | Search | Go }

• What is it?
• The Plug-in's progress
• Download
• Build
• Installation
• Usage
  • Troubleshooting
• Documentation
• User feedback
• Development
  • Interfacing with the compiler
  • AST
  • Syntax Highlighting
  • Compiler Invocation

What is it?

The funny thing is that the plugin itself is written completely in Nice.

enjoy!

The Plug-in's progress

• completed parts
  • creating nice project
  • switching to Nice perspective
  • opening Nice files in a Nice editor that uses Syntax highlighting
  • the nice.jar is integrated in the plugin lib/ folder
  • projectProperties implemented, invokable only in resources perspective
  • niceBuilder implemented that knows how to build the project
  • compiled binaries are stored in a jar file. If no jar file name is specified in the project properties panel, then the name of the jar file is by default "project.jar"
  • the main package can be set on the projects property page
  • invoking the compiler.
  • compilation progress is implemented
  • compilation errors and warnings are listed in the "Problems View"
  • design of basic icons
• todo as next
  • Nice general Preferences
  • debugger
  • Nice compiler should use a central nice.jar on the system
  • ...

Download

Build

• nice.runtime - path to the nice.jar file
• eclipse.home - path to the eclipse home folder

The following targets are available:

• compile - compiles all nice sources and creates a "niceplugin.jar" in the build folder
• dist - creates distributable versions of the plugin (.tar, .tgz, .zip) in the dist folder
• install - deletes old plugin version s from the %eclipse_home%/plugins folder and installs there the latest one

Installation

If you got the CVS version, then type:

ant install

Usage

• install the plugin with Ant as described before
• start/restart eclipse
• create a project of type "Nice Project" with the name "nice1"
• change to the "Resources Perspective"
• create a new Folder for the main package like "test"
• click on the "nice1" folder
• Menu "Project"->"Properties"
• select "Nice Project Properties"
• set main package: test
• leave classpath empty
• set jar name: nice1.jar
• create a new file "test.nice" in the "test" package
• type VALID code in "test.nice"
• save the file

now compilation should be started
a file nice1.jar is created in the "eclipse/workspace/nice1" folder

• make the code invalid
• save again

the error is reported to the console for debugging reasons
a "Problems" view should be opened with the error/errors

if the view is still empty then click on the black triangle on the right of the problems view title bar

select "Filters..."
check "Nice Problem"

• doubleclick on the problem entry -> select the line in the nice code

Troubleshooting

• Plug-in Details (the more info button should link to this page)
• Configuration Details

or look at the logfiles

• eclipsehome/workspace/.log
• eclipsehome/runtime-workspace/.log

Documentation

Plugin development guide: Plug-in Developer Guide (pdf)

Eclipse Naming Conventions

User feedback

Question:
How will this work in a multi-language project (say, Nice and Java, like in the Nice compiler source)? The source files will be opened in different editors, depending on the extension? -- DanielBonniot - 10 Jun 2003

Answer:
Yes, in the Nice-Project, that can contain diffferent file types, always the appropriate editor is opened. -- AlexGreif - 12 Jun 2003

Question:
What is Nice-Project? --Daniel

Answer:
with Nice Project I mean a special eclipse project Type, that was created by menu File > new... > Project... > Nice =. A Nice-Project knows which filetypes how to handle and how to invoke the compiler. In eclipse the terminus =Nature makes it possible that projects behave differently -- AlexGreif - 15 Jun 2003

Question:
If I write an ant build file for that project, will it be possible that compile errors are parsed correctly, depending on whether they come from javac and nicec?

Answer:
all errors should land in the task view, independently from which compiler. This is the desired solution. Isn't it? -- AlexGreif - 12 Jun 2003

Yes. But if the compiler was invoked by ant, I wonder how the information can be passed to eclipse through ant. --Daniel

If you build the project by ant, in a java-Project, all ant compilation errrors are "routed" in the Task view. If a java-project can to this, then we should be able to do this too :) -- AlexGreif - 12 Jun 2003

Question:
Does eclipse support Makefile too?

Answer:
I dont know, we have to look :) -- AlexGreif - 12 Jun 2003

I know, these are advanced features. I'm just curious. For the moment, support for Nice-only projects would already be great. Keep up the good work! -- DanielBonniot - 10 Jun 2003

Development

Interfacing with the compiler

See CompilationAPI.

AST

Looks useful to me. By the way, does the compiler offer a convenient way of obtaining the AST? Do we have a pretty-printer that will generate Nice source code from the AST? These could be important for this plugin (or others), if we want to support automated refactoring operations.

-- BrynKeller - 11 Jun 2003

No, the compiler offer no easy way to obtain the AST. And pretty-printing is only very limited because it's only used for creating *.nicei files. Both things could easily be implemented once the bossa.syntax package is completely converted to Nice. -- ArjanB

At the moment, the compilation API only allows a full compilation. It would not be very difficult to add an API to get an AST. It just needs to be defined: should we pass a package name and get back a list of AST for all files in this package and the imported packages? Or work on a file-by-file basis?

Pretty printing would need to be written (at the moment there is a toString method, but it won't create indentation, for instance). I'd suggest writing a Nice multi-method for pretty-printing, so it could be kept in a separate package. The root class for an AST is bossa.syntax.AST.

-- DanielBonniot

Syntax Highlighting

If you need it, I want to help the syntax highlighting since I familiar with the grammar of Nice and I have some time. -- ArjanB

We have to collect ideas how to realize syntax highlighting. My suggestion is

• when the user types nice code then the parser should be called immediately to return the sequences that should be highlighted
• or as an easy, static, alternative we define a set of syntactic rules like
  • comment - red
  • keywords - blue
  • class, interface - green you mean the class name? I mean the words "class" and "interface" themselves. It is just an example.

All editors that I know use the second way, they scan the source for strings and apply the rules in for of setting style and color.

Would it be possible to use the default colours used by the Java Editor (until we implement a Window / Preferences / Nice / Syntax notecard for selecting colours -- IsaacGouy - 19 Feb 2004

I think the first suggestion is better, because we let the nice parser determine which words are highlighted. On the other hand we have to measure how performant on the fly parsing is.

Maybe there is a way in eclipse to parse only the relevant parts of the edited document, and not the whole file all the time. -- AlexGreif - 12 Jun 2003

The parser is not very adapted for syntax highlighting because:

• it skips comments
• it does remember the location of keywords

It seems that we need three parsers, for the compiler (can be used for refactoring too), NiceDoc, and syntax highlighting. They are similar, but have different requirement. Does anybody know a way to share the common parts, while getting the different behaviours? -- DanielBonniot - 12 Jun 2003

yes that would be a good thing! -- AlexGreif - 12 Jun 2003

-- AlexGreif - 12 Jun 2003

I think implementing simple keyword highligthing is a good start. -- DanielBonniot - 12 Jun 2003

OKwe will take this for the first proto , then I can use the Ruby example :)) They do it the simple way too -- AlexGreif - 12 Jun 2003

We don't need three parsers because the NiceDoc comments could be parsed by the compiler and be put in the AST. This allow better linking between NiceDoc pages because the compiler can know wich method implementation belongs to which method definition and vice versa.

The parser for the plugin could be a lot simpler than the one for the compiler so sharing common parts might be not worth the effort.

-- ArjanB

I would prefer the parser in the final solution.

The question is, how should the parser return the syntax information?

• xml?
• proprietary format?
• List of Classes that contain info about CharRange+Style+Color

It depends how eclipse allows us to implement it, but IMO the third one is the best.

-- AlexGreif - 12 Jun 2003

For syntax highlighting, it seems to me the best would be to implement an generic SyntaxHighlighter?. It would take as input a java.io.Writer, and return as output a list of specifications: at such position there is a keyword, at such other position there is the name of a variable being defined, ... Would it be easy to do the highlighting in the text editor, given this info? -- DanielBonniot

That ist my third suggestion. Isnt'it? -- AlexGreif - 12 Jun 2003

It should probably be started in a low-priority thread, so it does not slow-down the system when writing. -- DanielBonniot

I have to examine how to start threads in eclipse. I think eclipse hast its own way to handle threads. -- AlexGreif - 12 Jun 2003

A good thing is that SyntaxHighlighter? could be shared among several editors (think JEdit).

If we think, in the long term, about refactoring, showing the definition of a class and automatic completion, which basically mean parsing the whole program, this could be seen as duplicating effort. On the other hand, it could be nice to have syntax highlighting on syntactically incorrect programs (when you are writing a method, and it is not finished yet), and then SyntaxHighlighter? needs to be quite different from a normal parser anyway. -- DanielBonniot

Maybe thats the way they have siple word matcher for syntax Highlighting -- AlexGreif - 12 Jun 2003

Do we know how code completion works in eclipse plugins? -- DanielBonniot

not yet :)) -- AlexGreif - 12 Jun 2003

Compiler Invocation

In the first run I will embed the nice.jar in the temporary (net.sf.nice.compile) plugin. This makes it fast to implement the plugin proto. If we get more experience how to handle only one nice.jar on the whole system, we will get rid of this temp plugin. -- AlexGreif - 12 Jun 2003

Question:
Should there be a way to specify compilation options (the main package, class directory, classpath...). -- DanielBonniot

Answer:
we should specify the most necessary things in the main preferences (Menu Window > Preferences > Nice). And project specific preferences can be set in the project itself. -- AlexGreif

Question:
Or should we require that the user writes an Ant build file to do that? (Is there a good assistant to write build files? Or maybe the nice plugin could contain an editor to create sections in a ant build file specifically for the nicec target, listing the available options?). -- DanielBonniot - 12 Jun 2003

Answer:
Only ant script is not enough. Its not very user friendly. There is another plugin that lets one build ant scripts. we can make our plugin dependant on the ant-plugin. -- AlexGreif

I managed to compile a Nice project, by writing a ant build file! The editing was in a text window, but there was automatic tag completion. Is this what you were refering to, or is there something more user-friendly? -- DanielBonniot

Its another ant plugin. I deleted it two days before so I cannot tell whats it exacly doing. But it helps with editing the ant script maybe in a graphical way -- AlexGreif - 12 Jun 2003