[QScintilla] autocomplete question

[Phil Thompson]

On Fri, 27 Jun 2008 14:55:28 -0400, "Gedalia Pasternak" <gedalia at gmail.com>
wrote:
> Hi ,
>   I've been trying to work with the qsciapis to trigger some complex
> autocomplete responses.
> it seems like qsciapis are only designed to handle global functions, or
> function where the object name is known.
> 
>    I'm wondering if there are any facilities for something more object
> oriented.
> I'm trying to implement this for lua, so valid function separators are
'.'
> and ':' if I know the class of the object on the left side of the
> separator
> is there any way to get an autocomplete list with a list of that object's
> members.
> 
> showUserList seems to be my only option, at the same time it seems a bit
> dumb:
> 
> slotTextChange()
> {
>     int line_num;
>     int index;
> 
>     m_textedit_code->getCursorPosition(&line_num, &index);
>     QString line = m_textedit_code->text(line_num);
>     QChar curr_char = line.at(index);
>     if(curr_char == ':' || curr_char == '.')
>     {
>         QString current_line = line.left( index );
>         QStringList list = QStringList::split(QRegExp("[
> ]|[(]|[)]|[[]|[]]|[;]|[,]|[\n]|[\r]"), current_line);
>         QString object_name = list[list.size()-1];
>         if(object_name == "Known_Object"){
>             QStringList function_list = QStringList::split(" ",
> QString("foo1 bar2"));
>             m_textedit_code->showUserList ( 1, function_list);
>         }
>     }
> 
> Unfortunately the autocomplete box instantly disappears because
> AutoComplete::autoHide defaults to true, and qscintilla thinks none of
the
> possible replacements has a ':', even if I add a ':' to the various
> function
> names I don't get the nice eliminate "all the non potential matches"
> behavior of the qsciapis code.
> 
>    Currently qsciapis seems somewhat hard coded with no virtual
functions,
> or slots/signals, is there any sample code floating around that might
help
> me?

I agree that the API isn't very flexible. To get the functionality most
users probably expect requires deeper knowledge of the particular
programming language than a Scintilla lexer has. The expectation was that
an application would provide additional API information dynamically - but
there are some problems with the API that make this difficult. I hope to
address these (to some extent) for the next version.

Any suggestions welcome.

> P.S. as long as I'm posting... can anyone tell me why the default lua
> Lexer
> seems so much less visually appealing then the perl one? Keywords and
> special characters in Perl appear bolder and it just generally seems more
> readable. Unless I'm messing something up, It seems odd that things
aren't
> more uniform.

That's down to the defaults in the QSciLexerLua class which should reflect
the standard SciTE properties. Override them if you don't like them.

Phil