We want to help developers write code. One way to do so if to give them quick information on errors, and also options as they type.
Malte Ubl has created bespin.editor.codecompletion which currently analyzes the current source file (and knows about a few special chaps like "bespin") and uses that information to share possible code completion paths for you.
There are a few todo actions:
Add nice UI to completion
Here is a mockup of two forms of undo. Images for the implementation are provided at the bottom of this page!
First up is the scenario where there is one potential guess of what you are typing:
As you can see, there is a light grey completion inline, and if the user hits TAB it will complete.
What if there are multiple options?
Here a drop down shows the options available. The first option should be highlighted and UP and DOWN arrows can get you through the list. If the completion is a literal completion of the word that is being typed it should have the greyed out effect as the single option has above. This means that text can rotate as you go through the options.
However, if in the future we have more advanced completion where something like "gFB" shows a completion for "getFoobar" then we do NOT show the grey.
When to complete?
When does completion kick in? Malte has currently got it automatically working on special characters (e.g. when it sees a "."). I think we should have:
- set autocodecomplete on: This gives you the Malte world (Note from Malte: I like key bindings, too, but the other thing was easier to implement)
- Ctrl-/ explicitly tries to do a complete
Current Engine Design
The current was like this:
- The syntax engine publishes events with meta data about the current document.
- These events are observed by the code completion engine
- Thus the code completion could work with many languages because it doesn't know about the parser that fetches the meta data
- The following data is used for completion
- function names
- class names
- "chained identifiers" like foo.bar.baz
- When the code completion is asked to complete the current input, it looks back from the current cursor for something that looks like the start of something that can be completed. This part is currently specific to JS but might work pretty well for other mainstream languages.
As mentioned, we started off with a simple notion of completion, but in the future we would like to have metadata that is used to do more advanced completion. The project as a whole will publish analysis data into a metadata structure that is shared. This structure will allow the lookup engine to complete on an object that is created elsewhere.
We should look into how we can use hints to tell the system what is happening. Libraries are using various sources right now, such as SJDoc and OpenAjax has taken that on pretty much as is. This means that we can analyze the doc formats to grok libraries such as Dojo, Prototype, jQuery, and anything that is marked up.
We also want to experiment with real time analysis where we probe objects themselves to find out which methods they have.
This work all ties into snippets, which will be spec'd out in a separate design document.
Images for Implementation
You will find the sliced images in the frontend/images directory with the prefix codecomp_*
frontend/images/codecomp_btm-lft.png frontend/images/codecomp_btm-mid.png frontend/images/codecomp_btm-rt.png frontend/images/codecomp_item-bg.png frontend/images/codecomp_lft.png frontend/images/codecomp_mid.png frontend/images/codecomp_rt.png frontend/images/codecomp_top-lft.png frontend/images/codecomp_top-mid.png frontend/images/codecomp_top-rt.png