[Github-comments] [geany/geany] Enable local variables for C/C++ and improve autocompletion (PR #3185)

[Jiří Techet]

> Please, if I wanted to discuss the in this PR, I wouldn't have asked to separate it out.

This is the core of the issue for me - your "I don't want to discuss it" (and possible subsequent "prepare another PR and I'll nix it") is maybe comfortable for you but is much more work for me and since we will have to discuss it anyway, I don't want to spend my time implementing something which doesn't get accepted.

I also don't agree this isn't relevant to this PR - it affects the ordering of symbols which is important both for scope and non-scope autocompletion and the result of the discussion affects how autocompletion works which is the main part of this PR.

So once again, I'd like to have it discussed now. I could create a separate issue for it but since it's so tightly coupled to this PR, I don't see a reason why not to discuss it right here.

> For example, if the requirement is to autocomplete class members then I would search for tags within the class, regardless of which header file (if any!) contains that class declaration.

That's not what this is used for - scope autocompletion does work the way you describe.

For **non-scope** autocompletion (aka "the simple one returning everything") this serves for improved ordering of symbols. If you meant you'd also search for classes like in the scope autocompletion, I don't really know how I'd do something like that efficiently. One could probably do some hybrid autocompletion where the non-scope autocompletion would also do scope autocompletion stuff as part of it but then you'd have to somehow have to merge it with the rest of the autocompletion symbols and this would have to be reasonably efficient. Right now I don't feel like I'd want to rewrite non-scope autocompletion in some major way like this.

But it's not only about members of classes but also other symbols defined in the headers - and I just don't see what's wrong if symbols from the included headers will be higher in the list than the rest of the symbols. Or in other words, now the symbols are sorted just alphabetically and alphabetic ordering has no relation to how relevant the given symbol is to the current file. Wouldn't ordering the symbols based on whether the symbol comes from the included file improve the situation?

For **scope autocompletion**. Imagine you have 2 identically named symbols `name` of different (structured) types defined in two different files - totally common for big projects. If you pre-order the symbols so that those from included files are examined first, you increase the likelihood that the one you are going to examine first is the right one. Is the result guaranteed to be perfect? Not. Is it better than picking a random symbol from workspace called `name`? Definitely.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3185#issuecomment-1121213405
You are receiving this because you are subscribed to this thread.

Message ID: <geany/geany/pull/3185/c1121213405 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20220509/0e87c268/attachment.htm>