<br>Right now we have a KCompletion object in the SearchContext, runners can add there their completions. Aseigo proposed to change that to a new CompletionMatch type&nbsp; (in SearchMatch::Type ) so we use for completions the same data path than for matches. Also we can win completions with not only text but any information relevant to a real match.<br>
<br>As the GUIs will likely receive matches in bulks (in my krunner patch). It is inefficient and
redundant between GUIs to make them search the list of matches for completions,
display them and&nbsp; delete them from the matches list if needed (note that
generally completions and other mathes will have different GUI
representations so they will likely be distinguished). So I propose two options:<br><br>- matches() accepts as parameter the type of match you want (can be
or&#39;ed or left black for all the matches), so we avoid every GUI
implementing this. Note that the implementation of this method would be
create a sublist (comparing the type() or each entry) from the list and
return. Not specially fast ...<br><br>
- Internally have 2 matches lists, one with completions and one with
everything else.&nbsp; We can provide the above method anyway but in the
likely case of retrieving completions or in the case of retrieving the
others, no sublist is done.<br clear="all"><br>I implemented the second one but it looks a little bit ugly...<br><br>-- <br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a href="http://www.bahasara.org">http://www.bahasara.org</a><br>