[QScintilla] Call tip problem

[Phil Thompson]

On Tue, 16 Sep 2008 17:53:49 -0400, "Paul Kerchen"
<pkerchen at simcreator.com> wrote:
>> From: Phil Thompson [mailto:phil at riverbankcomputing.com] 
>> Sent: Tuesday, September 16, 2008 5:07 AM
>> 
>> 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.
>> 
> 
> Hi Phil,
> Thanks for your thoughts. I'm quickly coming to appreciate why you've
> given
> up trying to make auto-completion and call tips right for everyone all
the
> time. :)
> 
> I created a new lexer that inherits from QsciLexerJavaScript.  The only
> differences between my lexer and its base class are in
> autoCompletionWordSeparators() (added ")." and "]." ) and
wordCharacters()
> (added '(',')','[' and ']'). That new lexer got me a lot closer to where
I
> would like to be, being able to handle significantly more complicated
> expressions without any trouble.  However, there are still some
> expressions
> that don't make it past contextWords() (for example, the double in the
> expression "foo.bar(3.14).boom()" makes contextWords() give up).  I don't
> know how these changes affect other parts of Qscintilla since I'm
> bypassing
> some of its functionality anyway (I don't use the "automatic"
> auto-completion functionality--I use user lists instead--and I'm
> explicitly
> calling callTip() when necessary), but of course adding my own custom
> lexer
> doesn't affect anyone but me. ;)  However, being able to make a more
> specialized version of contextWords() would be useful for me, so I would
> vote in favor of making it public and virtual.

It will be in tonight's snapshot, but called apiContext().

Phil