Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Despite the heroic efforts of the Uctags crew and @techee and others there are some limitations that Geany can't overcome when using assistance features in C++.
Since its come up a few times in various issue/PR discussions I thought it might be useful to summarise the fundamental limitations imposed by the underlying design of the Geany/Uctags/Scintilla combination in relation to C++. Or to put it another way, how C++ has outgrown that design which was "adequate" for plain C.
I concentrate on C++ because I use and know it and because it has a Uctags parser that is more capable than most and because it manages to include nearly all the problems that the Geany design has for other languages
Hopefully an overall understanding of the limitations can guide a coordinated approach to heuristics that attempt to improve usability rather than individual heuristics being applied independently as happens now.
These are in no special order.
Scintilla semantic styling (keywords, types, and the rest) for names is global, but C++ can re-use names for objects with different semantics in different scopes (foo can be a type in one scope but a variable or function in another), in different contexts (eg final and override are only keywords in specific contexts, they are variables elsewhere), and even in the same scope if a name is a struct/class/union type, a variable of the same name is allowed and hides the typename.
Idioms like "first letter caps"ing typenames help, but the STL, Boost++ and other major libraries have all lower case typenames, so if there tags are loaded local variables of the same name are shown by Scintilla as types.
Can't follow includes, neither Geany nor Uctags can see includes because the dependencies are specified in the build system and neither can understand those. The result is that the information provided to users is compromised, see below.
Types of declared entities depends on declarations in the include files, which are not read, so the variable type is just an opaque name, no members, member functions or constructors information is available either to Geany or the user.
Types of expressions are not deduced so inferred types cannot be deduced, eg auto a = foo(bah); This is for two reasons:
a. Uctags doesn't have any capability to do it, even the type of 1 + 1.0
b. even if it did have the capability the lack of accurate type information and template definitions from the include files means it cannot.
The lack of type information means that assistance features (autocomplete, calltips) are empty.
To avoid the total lack of accurate assistance features Geany attempts to use name based lookup, but that spams the lists with many irrelevant names. There is some attempt to filter or to rank by relevance, but its not particularly good simply because it does not have the information to work off.
Tags do not provide lexical scope information for variables, so name hiding cannot be deduced, so again name based lookup will show irrelevant options.
When C++ modules start being used in the wild they will suffer from all the include file problems and a few extras.
How do a few other editor/IDEs do it?1
I am somewhat surprised at how fast LSP use has infiltrated the big guys like MS, Eclipse, and Apple although C/C++ are still supported by legacy code that existed before LSPs in some cases.
So am I suggesting Geany should use LSPs, probably not, the previous attempt to use clangd showed that hard coded ways of doing things is heavily entrenched in Geany, its would take nearly a rewrite. Geany 2.0/GTK4 "somebody", anybody?
this list is to the best of my and googles knowledge in 1/2 an hour, it may contain erorrs and is certainly incomplet
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.