Hi!
If you think this filtering is fast enough we can do that. But the file filter list will have 50-300 entries.yes but if you use the 'packages' grouping you would not require to pass all those entries to a single query.
Yes, but it wouldn't work as good as single file filtering. And in addition what would we do with files that aren't part of any package because they are system headers or just part of a library that's not using pkg-config? As said before, I don't see much benefit for the package filtering in general.
well, nope. But I'm not sure that a recursive query that searches into parents scope can be written. That's why the cxxparser was written, to give an help in these kind of situations. @IANJUTA_SYMBOL_QUERY_SEARCH_PARENT_SCOPE: Query to get the parent scope of a symbol. This query isn't really easy to calculate, and thinking to put the procedures to search the parents recursively is hard.
cxxparser is great to detect situation like object->method() but it
doesn't help us with scoping in the global database. But we would really
like to have autocompletion for this case:
Class MyButton : Gtk::Button
{
}
MyButton::do_something()
{
set_label ("Something"); // this is a method of Gtk::Button
// but Gtk::Label might also have a similar method that we don't
// want
}
Of course we can do something like that in the language-support plugin
(sync pseudo code):
for (scope = current_scope; scope != NULL; scope =
scope_get_parent_scope (scope)
{
symbols = g_list_concat (symbols, find_symbols_in_scope (scope));
}
But I though that there might be a faster way using database queries. If
there isn't we have to do it this way.
Regards,
Johannes
Attachment:
signature.asc
Description: This is a digitally signed message part