Hi all,

We (Frederic Simon and Dror Bereznitsky) are happy to show you a pre-alpha version of a Fan IntelliJ plugin. You can read more about it here (http://wiki.jfrog.org/confluence/display/FANP/Home). The current version is usable but has a minimal features set. We are confident that progress will be swift from this base, especially if good minds will be helping with tests, QA, feature requests on Jira, and in pure development with patchs for the mercurial repository.

The basic features of this version 0.0.1 are:

1. Syntax highlighting
2. Building a Pod and Java stubs
3. Running a Fan script
4. Fan module support
5. Fan SDK support
6. Structure view
7. Searching for a class name

For the moment Expressions and Method blocks content are not parsed, so no code completion or error highlighting inside methods.

Hope you'll enjoy this pre-alpha version, and we waiting for your comments,

Dror and Fred a team of frogs :)

-- http://www.jfrog.org/

This is really cool! I'm going to give a try on Wed.

What are your thoughts for code-completion?

One thing I would like do is build a service to run in the background do the parsing to maintain the AST, which all the various IDE projects could leverage.

I've been using it all day and it's pretty nice as far as it goes. It doesn't quite get some of the syntax highlight/validation right, but it's pretty good for such an early release. I still haven't quite figured out how to get it to build from within IDEA but I haven't spent too much time on it. Trying to chase down bugs and finish features have taken precedence. I'm going to try to take a look at the code as well and see if I can't pitch in. I'd been contemplating writing one myself, but I'm not really a plugin guru.

Great job, guys and thanks for taking this on. IDE support is, sadly, a prominent criteria for many shops when it comes to adoption.

Thanks for trying the plugin out :-)

cheeser - the wiki has some instructions on how to setup a development environment

As for code completion - it is planned for next versions, see FANP-11

About parsing and AST building in the plugin:

1. IntelliJ provides the full infrastructure for parallelism (background), Flex Parser, Indexing, Caching and Serialization (having the full AST of all the files can kill your IDE very fast :) You have already Camel Case index: Do Ctrl+N and "CO" gives the CompilerOutput class, like shown in screenshots
2. We "only" need to provide a Lexer, a Parser, fill the indexes, an additional Annotators, and then most IDE features are provided. We still have a lot of features to add: Code navigation (Go to, Find usages), Code Completion, Refactoring
3. We used as examples the great Groovy, and Scala plugins that are open source, and that's the main reason we made it so fast :) So, thanks for Fan being late in the game!
4. An IDE Parser is inherently very different than the compiler parser. You want to provide on the fly help in the editor, recover fast from errors, and a nice list of errors. Today our parser is quite bad at it :( so it can only improve.

By the way one of the main issue we have is how to find the Pod name of a Fan file: FANP-16 If someone has an idea, please comment on the issue, Thanks for trying it out.

It would not really be useful to use the existing Fan parser/compiler, because it doesn't offer incremental parsing nor substring parsing.

Now it's certainly possible to write a parser for a compiler that does both incremental and substring parsing -- the Eclipse compiler for Java does just that, which leads to some rather interesting properties (partial compilation of not yet valid source files).

Such a parser is considerably more complicated, but produces much better error messages, is faster at recompiling partial modifications, and can be easily integrated into third-party editors and IDEs. If you had such a beast, then making an Eclipse plug-in for Fan would be very easy, and extending Flux with real-time syntax checking, code completion, and other features would be straightforward.

UNA can be setup to automatically compile Fan code in the background after a short pause after typing (500 ms), and when errors are detected, they are highlighted directly in the document (with tooltips that describe the errors). So far, I'm surprised to say, UNA's syntax highlighting for Fan is still the best, supporting variables in strings, time literals, and other features specific to Fan. However, the pseudo-real-time syntax checking is far from ideal, because of the duplicated work that must go on whenever a file is modified; much better would be an incremental parser that could provide subsecond feedback on syntax errors.

Another thing that's really needed is Flint (Fan Lint), because right now the compiler only emits errors.

I haven't ever actually written a parser for an IDE, so I'll take your word that it is a different beast - that seems to make perfect sense to me.

Still I think the key question is does it make sense to write this once as a standard Fan library, and then have all the IDEs utilize it?

It seems to make a lot of sense to me because we can all share the work and have a single library to maintain as we enhance the language over time.

But I guess I know nothing of the internals of Eclipse, NetBeans, IntelliJ, Una, etc to know if this makes sense. If all these IDEs have their own model for background tasks, AST management, etc that wouldn't work with a standard Fan AST engine then I guess we wouldn't achieve much reuse.

Still seems the preferred approach to me if we can make it work. My vision was something like a Fan thread which maintained the AST for the pod you were working in, and the editor sent it change events to text as you typed to reconstruct the AST. Errors would be reported back as well as the ability to query the AST for code completion etc.

Still I think the key question is does it make sense to write this once as a standard Fan library, and then have all the IDEs utilize it?

This does make sense. All the IDEs should be able to utilize a single implementation.

My vision was something like a Fan thread which maintained the AST for the pod you were working in, and the editor sent it change events to text as you typed to reconstruct the AST.

Yes, that's the ideal model. You get an insert/delete text event, and fire off change events for the AST (nodes added/deleted/changed), which should be wholly accessible to clients. Errors can have their own special listener.

With this level of support, implementing really nice support for Fan would be a piece of cake.

However, it does involve adding incremental, substring parsing. Maybe for a first pass you could ignore that and just see what you could get out of a whole-file reparse & tree diff, with whatever error recovery techniques you're using now (though eventually you do need first class error recovery to do refactoring and syntax highlighting with partial information).