Having 2 files, *xx.foo* and *something.c* open as C (assume the *.foo* was a header or something): <details><summary><em>xx.foo</em></summary>
```c int xx_foo(int n); ``` </details> <details><summary><em>something.c</em></summary>
```c int main(void) { xx_foo(); // (1) } ``` </details>
At `(1)`, neither autocompletion nor "go to tag" works, but calltip does.
Quick code look suggests that the `TMTag->lang` probably is wrong (I guess using the ctags-detected language (none?) instead of the actual parer's language?).
Causes real issues with a codebase full of `.hdl`s loaded as C++ (which are auto-generated headers included in just as auto-generated `.hxx`es).
@techee if you have insight that'd be amazing, otherwise I'll try and look at this deeper when (read: if :grin:) I get time.
If the filetype of `xx.foo` is manually set to `C` the symbols are parsed, and at `(1)` (well the line after) `xx_<ctrl>space` correctly shows `xx_foo` and typing the `(` shows the calltip correctly, so tags parsing seems ok.
So its more likely in the Geany code of auto-autocompletions and goto symbol definition (which doesn't work in `xx.foo` either, not just `something.c`).
If the filetype of `xx.foo` is manually set to `C` the symbols are parsed, and at `(1)` (well the line after) `xx_<ctrl>space` correctly shows `xx_foo` and typing the `(` shows the calltip correctly, so tags parsing seems ok.
Well, if you add a line after the existing `xx_foo()`, `xx_<ctrl>space` will likely complete from the content of the file rather than the symbols here (e.g. works for me, but I don't get a nice icon for the symbol, because it's *not* coming from the symbols but the wordlist from the current file). Try again removing the line I wrote, it doesn't work for me.
So its more likely in the Geany code of auto-autocompletions and goto symbol definition (which doesn't work in `xx.foo` either, not just `something.c`).
Hum, interesting, for me it works just fine if I e.g. add an additional line at the end of `xx.foo` and type `xx_`, it suggests `xx_foo` as normal with icon and everything.
will likely complete from the content of the file rather than the symbols here
Well `Edit->Preferences->Editor->Completions->Autocomplete all words in the document` is off, so it shouldn't, that sounds like a bug (another one).
Good catch!
The problem is actually #3268. After a closer inspection the ctags "local" flag detection isn't very profound - it checks source file names and if the file name has a header extension, then the flag is non-local, otherwise it's local. So for the `*.foo` extension, it's assumed to be a C source where `xx_foo` is local just for the file, which is wrong.
Another problem would be when a user has two files open, such as `foo.c` and `bar.c` and doesn't use anything like ProjectOrganizer that would parse also the corresponding headers. Then symbols from `foo.c` won't be visible in `bar.c`.
So while it's nice that #3268 reduces the number of possibly invalid autocompletion symbols, it's not good in its current form. We could either revert it completely or modify it a bit to honor the `local` flag only in cases where we can be absolutely sure the given symbol won't leave the current file (such as static declarations). I'll try to play with it a little.
So I had a closer look at what ctags does and I think we can actually never be sure whether the flag is valid or not so let's revert #3268 to be on the safe side. See PR #3457.
See #3490 for a possible fix of this issue.
I'm confused, what does uctags mean by "local"?
Its only at C++20 that the concept of "TU local" is formalised but "extern" and "static" have been about since C. Or do they mean "function locals", ie what C++ calls "automatic" and "thread_local"? I presume they don't mean "block locals" since uctags doesn't do scopes.
Or do they mean "internal" linkage (vs "external" linkage) which after all is what keeps objects "local" to a TU?
In tag manager, it's called "local", in uctags it's called "isFileScope" (which is a better name). It's those definitions/declarations that are valid only within a single file and which cannot be legally used outside of that file (like static functions for instance).
Closed #3454 as completed via #3490.
github-comments@lists.geany.org