So what does this mean for this specific PR? Should the query API take the possibility of an AST into account?

I don't think so.

IMO ctags tags and any other AST-based parser are fundamentally incompatible. There's no way to convert ctags tags to AST - they are more or less flat:

• you only know on which line a tag was defined but if there are two tags on the same line, you don't know which tag was first. This is the only ordering info and it's insufficient to build AST.

• not all parsers generate scope information so you won't have info about what's defined inside another tag.

If you try to do the opposite and convert AST into linear lists of tags, you probably lose the info you need for autocompletion.

This means I don't find it very realistic that TM could ever be used both for ctags and libclang. I believe the main goal of using libclang is to get better autocompletion and calltips (I find symbol tree, tag definition/declaration goto pretty good even when using TM because these don't require much context information). This means we could:

• keep TM on all the time and use it for symbol tree and tag definition goto
• plugins will be able to use it all the time (they won't have access to the "better" tags from libclang but I think they are only needed for autocompletion which the plugin that adds the libclang functionality will do anyway)
• have some callback mechanism that libclang plugin can register itself for doing autocompletion and calltip popup

I think we should be a bit realistic in what we can do and what we should do - Geany is a simple multi-language IDE and we should concentrate on keeping it that way and improving it. Dedicated language-specific IDEs can always be fine-tuned for the specific language's features but if I wanted this, I'd be using other editor than Geany (which I do when I use Android Studio and Xcode for mobile development). Having some super-generic symbol management system that will be half of the Geany's source code seems to be outside Geany's scope. I have no statistics but I suspect most Geany users use it mostly for scripting languages so we now spend like one year implementing this and only a small percentage of users will use it.

And for me one thing is clear - I won't be working on that myself.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.