As part of the work done on bug 568649 (JSTerm keybindings: tab-completion) a very simple completion algo has been implemented. It takes the console value, splits it up by ".", loops over all items, takes the properties from the object it's at and matches the found properties with the input value: Given: ==== a = { foo: { bar: 1} } input = "a.foo.b" Algo: === parts = input.split("."); match = parts[parts.length - 1]; parts.pop(); obj = window // for (let part in parts) > loop 1: obj = obj["a"]; > loop2: obj = obj["foo"] properties = all properties on obj result = all properties that start with `match` (in this case "b"). Whereas this is very simple, it works quite well when you have typed something like document.getElement a.foo.bar but just in simple cases. If you start using more `fancy`language features like: (typeof document).len<complete> a["foo"].b<complete> there is no longer a completion (the simple algo fails here). Also, if you have more then just one statement in one line, things fail: document.doSomething(); document.getEleme<complete> Ergo: The completion algo has to be tuned. === I was wondering if we could use some of narcissus code here. Narcissus has a JS lexer/parser that could be used for the analysis of the code. Also, narcissus comes with an interpreter, that executes the generated parse tree. Basically the idea is to take the input string, reduce it to the parts that are relevant (call this step A): input: document.doSomething(); a.[foo].b relevant: a.[foo] match: "b" parse and execute this (call this step B): result = narcissus_eval(relevant); and then match all the properties in `result` with `match`. Making the reduction (step A) might be possible without using Narcissus code but step B (executing the reduction) is not that simple. The `narcissus_eval` has to be a little bit special from the normal eval call. It has to quit when it detect an variable assignment, variable declaration, variable modification or function call. Otherwise calling the completion algo would change something in sandbox/browser, which it isn't allowed to happen. While writing I came up with the idea to parse the relevant code using narcissus parser, analyze the generated parsing tree if any assignment, variable declaration or function call is made. If the answer is no, we know that the relevant code is "save" to execute and we could use a "normal" evalInSandbox result = Cu.evalInSandbox(str, this.sandbox, "default", "HUD Console", 1); Any comment/idea/input is welcome!

Following ddahls suggestion I add Jeff as CC on this bug @Jeff, what do you think of this?

It would be nice to weight the completion so that the most likely case comes first, instead of alpha ordering. When I type document.qu the first item is queryCommandEnabled[1] and then a bunch of other queryCommand noise that I have no idea about. I'm trying to get to querySelector, which is way down at the bottom of the list. Doing this loses out on predictable ordering, and it's probably only possible for builtins, but I would enjoy seeing querySelector come up first. Maybe it's a good place for frecency? [1]: https://developer.mozilla.org/en/nsIDOMNSHTMLDocument#queryCommandEnabled%28%29

(In reply to comment #2) > It would be nice to weight the completion so that the most likely case comes > first, instead of alpha ordering. When I type document.qu the first item is > queryCommandEnabled[1] and then a bunch of other queryCommand noise that I have > no idea about. I'm trying to get to querySelector, which is way down at the > bottom of the list. > > Doing this loses out on predictable ordering, and it's probably only possible > for builtins, but I would enjoy seeing querySelector come up first. Maybe it's > a good place for frecency? > > [1]: > https://developer.mozilla.org/en/nsIDOMNSHTMLDocument#queryCommandEnabled%28%29 The problem with this is, that you need a list on how you want to sort things as well as the result is no longer predictable. That might cause confusion.

I filed bug 585991 about showing completions in a popup, which would decrease the need for predictability, I think.

Bug triage, filter on PEGASUS.

We put some effort lately on having better autocompletion, so I'm closing this bug. If there are specific bugs you are still experiencing, let's file smaller more actionable bug for them.