Usage of simplecomp even if a smart completer is available (config option)

[GoogleCodeExporter]

As discussed on the mailing list. As usual feel free to
discuss/modify/whatever.

*) AutoCompService is a completer itself. May use both simple and smart
completers if asked, or one only depending on the buffer.

*) New boolean configuration option SIMPLE_COMP in Document/Code. Not sure
if profile update is handled correctly.

Original issue reported on code.google.com by cow...@gmail.com on 21 Apr 2009 at 12:06

Attachments:

• simplecomp.diff

[GoogleCodeExporter]

Thanks,

will review sometime soon.

Original comment by CodyPrec...@gmail.com on 22 Apr 2009 at 3:34

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Ended up re-writing the whole thing to go with a different approach to avoid 
having
the AutoCompService from being a delegate for the Completer object. This is 
because I
would like it to simply be a factory for getting completers from and not the
interface it self, so when I get the plugin interface implemented things will 
work
transparently.

On a related topic, as part of the autocomp plugin interface I want to add 
support
for completers to be able to load user provided API files. I think that a good 
one to
start with for testing this would be to implement for PHP. It would be good if 
we
could generate an api file (in a format to yet be decided) from the languages
documentation if possible then it would be easily update-able. Would be good to 
be
able to have calltips attached to functions/classes when possible as well. Any
additional ideas?

Thanks,

Cody

Original comment by CodyPrec...@gmail.com on 26 Apr 2009 at 12:03

• Changed state: Fixed

[GoogleCodeExporter]

If you like the way SciTE handles this stuff maybe we can use the same API 
format

Original comment by cow...@gmail.com on 27 Apr 2009 at 7:51

[GoogleCodeExporter]

Yea, that definitely looks like a good place to start. After a brief overlook 
of it
there are some limitations that I would like to workaround/enhance. Instead of a
simple list of words it might be usefully to use a simple xml structure, so that
additional information can easily be added later.

i.e)

<function name="foo" help="foo() does something" args="None"/>

It would also allow for separate library dependancy checking

<module name="bar">
   <function name="..."/>
   <struct name="..."/>
   <class name="MyClass">
     <method name="someThing" help="Does something"/>
   </class>
</module>

This second example is probably more complicated than we would want to start out
with, but by using xml as the format it would be an option to expand to at some
point. For a base we could probably write a simple script to convert the other 
api
files to this format, it would be even better if we could use a languages
documentation to generate a file that includes help/method signature strings, 
being
able to see a methods arguments is usually the most useful.

Cody

Original comment by CodyPrec...@gmail.com on 28 Apr 2009 at 12:21

[GoogleCodeExporter]

That's pretty basic, you're right, but it also supports arguments and 
description,
i.e. an excerpt from php.api

abs(mixed number) Absolute value

However I think you should decide what's the target for this object. As I see 
there
are two options:
*) A simpler one, with minimal implementation and knowledge just about the 
basic builtins
*) A complex one, which would need to check dependencies, know about scopes ... 
but
this is kind of the same job as the smart autocompleters, right?

Original comment by cow...@gmail.com on 29 Apr 2009 at 8:25

[GoogleCodeExporter]

The idea is that deciding on a simple xml format could meet both. For simple 
builtins
it could just be a list of things like the following

<function name='foo' args='val1, val2' help='does stuff'/>
<variable .../>

Some 'smart' completers could also make use of this functionality by doing a 
simple
parse to determine the type/scope of an object then make a smart selection from 
the
api file(s).

I have a few other things I am working on right now but once I get them off my 
list I
will try to get some of this going.

As an initial target it would be best to just get the simpler one setup and 
working
first by adding an api file reader class that can load the files and create an 
in
memory representation of the file. That objects can be quickly indexed from.

Original comment by CodyPrec...@gmail.com on 29 Apr 2009 at 6:28

[GoogleCodeExporter]

Ok, let's start with a simple xml for builtins. I also suggest to keep backwards
compatibility with SciTE API files.
Drop a line on the list when you want to start.

Original comment by cow...@gmail.com on 30 Apr 2009 at 6:50