<br>>I agree that the API isn't very flexible. To get the functionality most<br>
>users probably expect requires deeper knowledge of the particular<br>
>programming language than a Scintilla lexer has. The expectation was that<br>
>an application would provide additional API information dynamically - but<br>
>there are some problems with the API that make this difficult. I hope to<br>
>address these (to some extent) for the next version.<br>
><br>>Any suggestions welcome.<br>
<br>Well the user list functionally seems much rougher then it could be for this purpose, I guess if it could share more of the qsciapi functionality that would be an improvement (automatic non-matching elimination, proper replacement of the typed text with the auto complete item chosen). <br>
Alternatively I'd envision that when a languages member accessor ('::', '->' '.') gets hit you'd have a callback that would give the api user the previous token or line/index info. The end user would then be required to specify a typename, which would map to a list of methods in the qsciapis object. At the api level those could be initialized with QsciAPIs:add(QString type, QString function), <br>
<br> In some respects there wouldn't even need to be that change, if you added "string.foo" and "string.bar" to the api list, the autocomplete could just treat the left side of '.' as the type and the right side as the method. you'd only need to create the callback function and a option to turn on, <br>
<br>-Gedalia<br><br><br><div class="gmail_quote">On Sun, Jun 29, 2008 at 8:40 AM, Phil Thompson <<a href="mailto:phil@riverbankcomputing.com" target="_blank">phil@riverbankcomputing.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, 27 Jun 2008 14:55:28 -0400, "Gedalia Pasternak" <<a href="mailto:gedalia@gmail.com" target="_blank">gedalia@gmail.com</a>><br>
wrote:<br>
<div><div></div><div>> Hi ,<br>
> I've been trying to work with the qsciapis to trigger some complex<br>
> autocomplete responses.<br>
> it seems like qsciapis are only designed to handle global functions, or<br>
> function where the object name is known.<br>
><br>
> I'm wondering if there are any facilities for something more object<br>
> oriented.<br>
> I'm trying to implement this for lua, so valid function separators are<br>
'.'<br>
> and ':' if I know the class of the object on the left side of the<br>
> separator<br>
> is there any way to get an autocomplete list with a list of that object's<br>
> members.<br>
><br>
> showUserList seems to be my only option, at the same time it seems a bit<br>
> dumb:<br>
><br>
> slotTextChange()<br>
> {<br>
> int line_num;<br>
> int index;<br>
><br>
> m_textedit_code->getCursorPosition(&line_num, &index);<br>
> QString line = m_textedit_code->text(line_num);<br>
> QChar curr_char = <a href="http://line.at" target="_blank">line.at</a>(index);<br>
> if(curr_char == ':' || curr_char == '.')<br>
> {<br>
> QString current_line = line.left( index );<br>
> QStringList list = QStringList::split(QRegExp("[<br>
> ]|[(]|[)]|[[]|[]]|[;]|[,]|[\n]|[\r]"), current_line);<br>
> QString object_name = list[list.size()-1];<br>
> if(object_name == "Known_Object"){<br>
> QStringList function_list = QStringList::split(" ",<br>
> QString("foo1 bar2"));<br>
> m_textedit_code->showUserList ( 1, function_list);<br>
> }<br>
> }<br>
><br>
> Unfortunately the autocomplete box instantly disappears because<br>
> AutoComplete::autoHide defaults to true, and qscintilla thinks none of<br>
the<br>
> possible replacements has a ':', even if I add a ':' to the various<br>
> function<br>
> names I don't get the nice eliminate "all the non potential matches"<br>
> behavior of the qsciapis code.<br>
><br>
> Currently qsciapis seems somewhat hard coded with no virtual<br>
functions,<br>
> or slots/signals, is there any sample code floating around that might<br>
help<br>
> me?<br>
<br>
</div></div>I agree that the API isn't very flexible. To get the functionality most<br>
users probably expect requires deeper knowledge of the particular<br>
programming language than a Scintilla lexer has. The expectation was that<br>
an application would provide additional API information dynamically - but<br>
there are some problems with the API that make this difficult. I hope to<br>
address these (to some extent) for the next version.<br>
<br>
Any suggestions welcome.<br>
<div><br>
> P.S. as long as I'm posting... can anyone tell me why the default lua<br>
> Lexer<br>
> seems so much less visually appealing then the perl one? Keywords and<br>
> special characters in Perl appear bolder and it just generally seems more<br>
> readable. Unless I'm messing something up, It seems odd that things<br>
aren't<br>
> more uniform.<br>
<br>
</div>That's down to the defaults in the QSciLexerLua class which should reflect<br>
the standard SciTE properties. Override them if you don't like them.<br>
<font color="#888888"><br>
Phil<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>---------------------------------------------------------------<br>cel: 917.776.8346 AIM: gedaliap<br><a href="http://www.gedalia.net" target="_blank">http://www.gedalia.net</a><br>
---------------------------------------------------------------<br>Fight Entropy!!! Fight Entropy!!! Figth Etnropy! !<br>iFgth Etnrop!y ! giFth tErno!py ! giFt htrEno!p y! --- Well maybe<br>not...