[Github-comments] [geany/geany] Use the official 'libreadtags' library from ctags for parsing ctags files (PR #3049)

[Jiří Techet]

> So if I understand you correctly the new parsers will give us a proper lexical scope (at least for function levels if not internal scopes) so we no longer need the hack of trying to align folds and declarations, and then it should be possible to reduce the noise a lot.

To be clear, I think right now it's only the C/C++ parser that parses function bodies and it may be the only parser that will ever do it. I think it was out of necessity as C/C++ are impossible to parse correctly without them (something that @dolik-rce did run into with the Kotlin parser too). Local variables were then thrown in as a bonus. But I don't think this is the feature that is in general planned for other parsers in ctags. And even if e.g. the Python parser started parsing function bodies, we are more or less blind regarding types in dynamically typed languages and those will be useless for scope completion.

> Well while we are at it, why not lump some more work on you, can we have a method of distinguishing overloads ;-)

Since the popup with autocompletion shows only names and not parameters and this list is made not to contain duplicates, there's no work for me :-). In the tooltip after opening a brace you can already switch among alternatives).

> Yes if the language says local names hide the global ones, but beware the C++ ::name that sees the global one, or Julia global x that does the same.
> Nor (as I ranted above) do we see members defined in classes which are automagically visible in member functions (for C++, or with "self" for Python or Rust) before inheritance is even considered. And that of course means identifying if a function is a member function/method or just a "plain function".

This is just too language specific and there are too many things like these to handle in general in the scope completion code I'm afraid.

> The Clang guys would be surprised to hear that ;-)

Let's be clear - what we are talking here about for Geany is stupid and naive scope completion (that doesn't behave in an annoying manner though). I myself don't plan doing anything advanced because I think (1) it's extremely complicated to achieve using plain tag lists instead of syntax tree with semantic annotations (2) it's a waste of time when things like https://microsoft.github.io/language-server-protocol/ exist which we should rather support in Geany to take over all the tag manager stuff when installed and which will achieve much better results.

But despite being stupid and naive, I think we can still show some useful results in many cases.

> Please note I am not just being annoying by bringing up the difficulties, exceptions, and issues above, I want to make sure all the weirdness of various languages are considered first so it can be implemented progressively, otherwise the first apparently simple solutions will block some of the more subtle later capabilities when you come to add them, and stuff will have to be undone or re-done leading to many massive PRs again, all with the tag-manager label 😁

Once again, I don't plan doing much in this area myself - apart from addition of inheritance information I would just make sure that tags from other functions don't appear in the results.

Primarily, I want to make some things that "feel right" regarding the tag manager so it's easy to add and update parsers, add new kinds, do some language-specific things at a single place so we don't run into the maintenance disaster we were before once again. If Geany can just update Scintilla and ctags easily and add support of new languages easily, we can have a new release "for free" even if we don't have much time to do something ourselves.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3049#issuecomment-991941241
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20211212/8f751135/attachment-0001.htm>