[QScintilla] Call tip problem

[Phil Thompson]

On Sat, 13 Sep 2008 09:45:31 -0400, "Paul Kerchen"
<pkerchen at simcreator.com> wrote:
> Hello All,
> I'm using Qscintilla as the text edit control in a JavaScript editor that
> I'm writing.  JavaScript is an OO language, so I'm using user lists and
> class-specific APIs to get Qscintilla as it stands today to do what I
> want.
> Currently, I can get the proper code-completion and call tip behavior
that
> I
> need for reasonably complex expressions.  For example, typing
> 'foo.bar.baz.process()' gives correct code completion options at each '.'
> and the correct call tip when the opening parenthesis is typed.  Here's a
> simplified code snippet that shows what I'm doing to get the proper call
> tips based on the context:
> 
>    expr = "foo.bar.baz.process(";
>    exprType = computeExprType( expr ); // A function I wrote
> 
>    // computeExprType() figured out that "foo.bar.baz" is of some known
> type, so
>    // we tell Qscintilla to use that type's API...
>    lexer->setAPIs( getAPIForType(exprType) );
> 
>    // ...and then immediately show the call tip.
>    textEdit->callTip();
>       
>    // If 'process' is found in the API associated with exprType, the call
> tip for 'process' is shown.
> 
> The problem that I've run into is in dealing with slightly more complex
> expressions of this form: 'foo.bar.oof().process()' or
> 'foo.bar[].kablooie()' .  Specifically, when I call callTip() at the
point
> the user has typed the right-most opening parenthesis, no tip appears,
> even
> though I've given Qscintilla a QsciAPIs with valid function call
> signatures
> in it.  I tracked the problem down to QsciScintilla::contextWords(),
which
> considers 'oof()' and 'bar[]' to be invalid sequences and therefore
> returns
> an empty word list in either case.  
> 
> I don't pretend to understand all the ramifications of changing
> contextWords() to deal with this situation, but it seems like it should
be
> possible to modify it to take this common programming idiom into
> consideration.  Or, is this a problem with the JavaScript lexer (since
> contextWords() is just using the separators given it by the lexer)? 
Would
> adding ")." and "]." to the JavaScript lexer's auto completion word
> separators do the trick or would that cause other problems?  I would
> appreciate any suggestions on the best approach to solving this problem!

The short answer is that I don't know if such a change would cause problems
elsewhere - try it and see.

It's very difficult to get auto-completion and call tips right (ie. quick,
fast and useful) and, to a certain extent, I've given up trying. Instead
I'm happy to open up the API to make it easier for people to replace bits
of the functionality with their own implementations. For example,
QScintilla v2.3 allows you to change the way APIs are stored.

If you found that changing contextWords() works for you, but might break
things for others, then I'd consider making contextWords() (or something
like it) public and virtual.

Phil