[QScintilla] AutoCompletion for object based languages...is it possible?

[Eric Fontana]

I noticed updateAutoCompletionList gets called every time
you type a "dot" i.e. "foo.bar.test" makes one call
with the list "foo", "bar", "test" as the context.

I could impose a naming convention for variables;

var reg = Application.addRegister("x");

print(reg.name);  // "x"

I would have to create entries for "reg" (variable)
by calling add() and then prepare() correct?

Is there any way to make the prepare call synchronous? 

reg::name Name property  

Thanks.



-----Original Message-----
From: Phil Thompson [mailto:phil at riverbankcomputing.com] 
Sent: Monday, October 27, 2008 1:46 PM
To: Eric Fontana
Cc: qscintilla at riverbankcomputing.com
Subject: Re: [QScintilla] AutoCompletion for object based languages...is it possible?

On Mon, 27 Oct 2008 12:40:46 -0400, "Eric Fontana"
<eric at carbondesignsystems.com> wrote:
> Well; I've been experimenting with the AutoComplete (QsciAPIs) api and
> got
> 
> it working, however its not that useful without the next step;
> 
>  
> 
> I have an embedded QtScript object in my app, I registered a global
> 
> property "Project" to access it from the Script.
> 
>  
> 
> When you type "Project" (dot) "Project." the autocomplete pops up
> 
> and I can select a method name ,that works great.
> 
>  
> 
> Howerver, if a method returns an object, lets say for example:
> 
>  
> 
> var x = Project.Color;
> 
>  
> 
> If color was a QObject which had a name property I can type
> 
> 
> 
> x.name
> 
>  
> 
> However, since "x" isn't known to the autocomplete api, it's not known.
> 
>  
> 
> Is there a way to know when "x" is defined "var x = ..." easily?
> 
>  
> 
> I also noticed that the load() method doesn't support a return type
> 
> from the loader file.
> 
>  
> 
> Has anyone done this before?

QsciAPIs requires the user to provide enough information to know what to
do. If you entered "x.set" then the autocompletion list will contain all
API words starting with "set".

If two types have a method called "set" then both will appear in the list
and the type will also be shown. If the user selects, say, the "set
(Project.Color)" entry then it infers that the type of "x" is Project.Color
and uses that to restrict what is shown in later autocompletion and call
tip lists. This information isn't cached, so if you move to a different
line and back again then it forgets the type.

The alternative is to provide your own QsciAbstractAPIs subclass that
extracts the API information using whatever means is appropriate to the
language being edited. For example with a dynamic language you might be
able to create the "x" object and introspect it. With a static language you
might be able to parse it and get the type of "x" from the parse tree.

Phil