I've been trying to use Flux to do most of my Fan editing. It's nice, but it still needs some work before it will be as fluid as other editors. Luckily, I am finding it very easy to develop.

I made some enhancements to the Flux interface. I'm new to Mercurial, so I don't know how I would go about committing these to the main Fan repository.

The features I added are:

• An empty address opens flux:start instead of can't resolve Uri error.
• You can specify multiple files at the command line. Each opens in a new tab.
• In the search box, you may use the enter key to search for the next match.
• Closing the search text box focuses the editor instead of the toolbar.
• Ctrl+f when search box is open sets focus to the search box instead of the editor.

Please let me know how I can get these committed!

In general with distributed VCS the easiest route is to:

1. Clone the official repository to your hard drive
2. Make the changes you want to share and commit them to the local clone.
3. Push the local clone to a free hosting site like FreeHG or bitbucket.
4. Send a notice to the project maintainers, requesting them to pull your changes.

Thanks qualidafial. I'm actually already working on it with Brian and Andy.

Decisive Flux enhancements

• Code completion.
• Error highlighting.
• Building & Running of pods and scripts.
• Documentation & Source integration.

In my mind these features will increase the level of adoption of the language in the following ways:

• Aid the learning of the language and APIs.
• Provide a productive environment in which code can be developed efficiently.

Rest assured, geo, that all those points are on the list.

Search the forum. You'll see that IDE integration is one of Fan's major concerns. It'll get there ;-)

I'm working on pretty much the same list, I think. All those things are good. Overlap can lead to wasted effort, but different approaches leads to new ideas, that can always be rolled in to the official version.

To avoid stepping on other people's changes, or having mine stepped on, I'm developing a separate pod I call ReFlux, as in experimental Flux. I've currently got working a pod browser that runs as a second sidebar and shows the tree of available pods and all their contents that are available through reflection, as popup tooltips. This includes all the doc comments for types and slots (assuming they're included in the build). Also icons to differentiate between enums, mixins, types; fields, methods. So to see available enums you can hover over the enum name and see its possible values, for example.

I'm now working on a fan editor, which could be presented as an alternative viewer in normal Flux. Folding of code with tooltips so you can hover a folded line and see its definition, is what I'm working on now. Code completion is probably next. Some hopefully extensive drag and drop of nodes is on my list. Also I've looked at the Wily editor http://www.cse.yorku.ca/~oz/wily/index.html for ideas about more sophisticated and fast reorganizing of code.

Once I've got a good folding editor something like the Whisker Browser http://www.mindspring.com/~dway/smalltalk/whisker.html is very high on my todo list.

As I said, some of what I do may hopefully get incorporated in regular Flux, some may not. I wanted to stay a bit separate so I can put up what I do for review and comment; if it's decided to do so then I'll roll it into Flux; otherwise I'll at least be able to have what I personally like.

I'm rather convinced that syntax highlighting and autocomplete and so on should all be provided by semantic information from the actual compiler.

My other big feature I want (in addition to refactoring stuff) is reference hierarchy. Who references this, and who references that, and so on down the line in a tree. They have this in Eclipse sort of, but it only does this for method calls instead of including var references, too. It also annoyingly doesn't sort results.

Oh, and the ability to see all implementations of a particular method is also a nice feature from Eclipse that I use all the time.

And the quick outline (unexpectedly with Ctrl+O) with filter-as-you-type navigation in the class from Eclipse is also nice. I almost never use their separate outline view.

Just listing off my wishes again in disorganized fashion.

Oh, and I don't much care for code folding. And I usually like all tools centered around the text editor available instantly on demand rather than say doc navigators.

An additional item of great interest to me is code refactoring, starting with the simplest, automatic renamings applied to all references of a type/slot/variable. See http://www.refactory.com/RefactoringBrowser/Refactorings.html for the canonical list of automatable refactorings.

With Fan's clean syntax, good reflection, and some access to the parser and the AST, many, most, or maybe all of those can be done.

Automating the build another good thing that's coming. Right-click options in appropriate places to Create Pod, select pod and Add Class/Enum/Mixin, select a type and Add Field/Method; etc. Drag and drops or right clicks to move or modify; using refactorings to automatically update references...

This is some cool stuff, just my opinion.

Oh yeah, one more easy feature is, you know how those tree-lists of pods or types can get annoyingly long, you can't find anything without scrolling up or down all the time, and the mouse-gestures are difficult so it's a pain. Option to sort list by most recently seen would keep things where you could easily find them.

One more idea, I wish I could get to sooner. Dynamic configuration dialogs for Flux.

The Tools menu currently has the neat feature that you can add tool definitions, in a special directory, and click Refresh to get them dynamically added to the menu.

We need configuration dialogs for a number of things in Flux. Those could easily be done the same way, I think, and developing/tweaking them would be much easier and quicker.

Off the top of my head there needs to be an Editor Options config dialog; a Build Options dialog; General Options for location of fan environment, source tree, Java and .NET options; the lib/sys.props needs a dialog; lots of stuff. Maybe there should be a subdirectory FANROOT/flux/dialogs beside the existing FANROOT/flux/tools where these could be put.

Off the top of my head there needs to be an Editor Options config dialog; a Build Options dialog;

I think a more powerful way of looking at the problem is how can I generate a dialog for any arbitrary serializable object tree? Since all options are really just serialized objects stored in a text file, that could really just a be a special view on files ending with the ".fog" extension.

Here is an example:

class Address
{
  Str street
  Str city
  Str state
}

I should be able to use a reflection to build an editor on the fly which provides me three text fields with appropriate labels and knows how to load/store itself from an Address instance.

And the quick outline (unexpectedly with Ctrl+O) with filter-as-you-type navigation > in the class from Eclipse is also nice. I almost never use their separate outline view.

@tompalmer - I've never seen that feature, so maybe its the same thing as I'm thinking. But I think an Alt+Space feature for all the slots on all the types in the current file, and let you jump to each one, would be pretty slick. That hits the sweet spot for me.

One more idea, I wish I could get to sooner. Dynamic configuration dialogs for Flux.

@KevinKelly - Yeah that is something we never got too. I think a generic Dialog that simply reflected the fields would cover most cases. And if not, we'd probably use the typedb to look up custom dialogs.

EDIT: Though its probably Panes vs Dialogs, then we can condense all the different tools into a single dialog, with tabs or something.

But I think an Alt+Space feature for all the slots on all the types in the current file, and let you jump to each one, would be pretty slick. That hits the sweet spot for me.

That's pretty much the same idea. I would totally love to see this.

Side note, as I recall, Flux already has some areas (for recent files?) with filter-as-you-type functionality. If I'm remembering that correctly, just my vote for more of the same. Filter-as-you-type is totally the way to navigate huge lists. I mean, it even works at Google for the whole internet.

@tompalmer

They have this in Eclipse sort of, but it only does this for method calls instead of including var references, too.

Actually Eclipse can find references to local vars and fields too. Just place the cursor on the var/field name and type Ctrl+Shift+G.

Actually Eclipse can find references to local vars and fields too.

But not hierarchies. The call hierarchy feature sadly applies just to method calls.

Furthermore, if they had a generic reference hierarchy feature, there'd be no need for this redundant feature set of references vs. call hierarchies. They really need to unify all that.

Speaking of which, I highly recommend vigilance to avoid redundant, not-quite-compatible feature sets both in Flux and in Fan itself.