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

• The Plug-in's progress
• Download
• Install
  • Troubleshooting
• Documentation
• User feedback
• Development
  • CompilationListener
  • AST
  • Syntax Highlighting
  • Compiler Invocation

The Plug-in's progress

• completed parts
  • creating nice project
  • switching to Nice perspective
  • opening Nice files in a simple editor
  • design basic icons
  • Nice general Preferences: panels are there, and a sample editor pref. is finished
  • the nice.jar is integrated in a plugin
  • projectProperties implemented (only a dummy and skeleton) invokable only in resources persp.
  • niceBuilder installed that knows how to build the project (just the skeleton)
  • the main package can be set on the projects property page
  • invoking the compiler.
  • compilation progress is implemented, messages are shown too
• todo as next
  • display errors in double-clickable way
  • syntax highlighting
  • design icons
  • debugger
  • Nice compiler should use a central nice.jar on the system
  • ...

Download

• net.sf.nice.core
• net.sf.nice.ui
• net.sf.nice.compile

the downloadable jar (v0.0.5) contains the two folders. you can download here:
nice_plugin

Install

Troubleshooting

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

-- AlexGreif - 08 Jun 2003

Documentation

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

Eclipse Naming Conventions

User feedback

I just tried the plugin. Installation was very easy! I could create a new project, a new folder hello, and a file hello.nice. To go farther, I would need to be able to compile my project! :-)

Question:
If I understand well, a perspective is a set of windows that fill the screen at some point. The Nice perspective has "Nice resources" and the text editor. Note that when I created a Nice project, it did not switch automatically to the Nice perspective. Is this normal? -- DanielBonniot - 10 Jun 2003

Answer:
I will investigate how to set the default perspective. -- AlexGreif - 12 Jun 2003

Question:
In the "resource" perspective, there is a "task" window. That's where compilation errors will go in the future, right? -- DanielBonniot - 10 Jun 2003

Answer:
In the first drop we will present all compiler output in a console window. But later, yes the task view will list all errors and warnings... and the user can then double-click the error and lands in the appropriate line. -- AlexGreif - 12 Jun 2003

The compilation listener is already implemented. So maybe you can skip the console step. --Daniel

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

CompilationListener

A first idea for the listener is:

interface CompilationListener
{
  error  (Location location, String message);
  warning(Location location, String message);

  /** Reports the progress of compilation.
      phase can be: parsing, type-checking, generating code, ...
      the package can be null if the phase applies to the whole program (testing dispatch, creating the archive, compiling to native code, ...).
  */
  progress(?String package, String phase);
}

I might work on this today.

-- DanielBonniot - 11 Jun 2003

I would add a method "message(String)" for general messages.

All messages should be identified by a precise kind, I think. --Daniel

ASAIK other compilers go the other way:

interface CompilationListener {
  message(CompilationMessage);
}

class CompilationMessage {
  String getText()
}

class Error extends CompilationMessage {
  int getLine();
}

class Warning extends CompilationMessage {
 int getLine()
}

class Progress extends CompilationMessage {
  String getPackage();
}

-- AlexGreif - 12 Jun 2003

Is this better? One drawback is that it encourages to catch the generic message, thus losing information. I think a listener will take different actions depending on the kind of message, so we might as well call different methods for that. --Daniel

I dont know it this is better, Pizza did it this way and I think javac too. I was quite happy with this solution. There are only some types of Information that the compiler returns, so may be both are good. We schould start with yours and see how it involvs. -- AlexGreif - 12 Jun 2003

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.

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