I'll try to test it properly tomorrow, but the approach, although a bit of a workaround (as it's basically overriding a similar check in uctags), it looks pretty good indeed (esp. with the discussion on the uctags PR).

What about header files, why are they not C/C++ source?

Since (IIUC) the cause of #3454 is the intention to limit the symbols visible at any point by using heuristics (originally dodgy uctags ones) to exclude symbols that definitely can't be visible. The "its not the same language so it can't be visible" heuristic is the cause of the OP of #3454 exacerbated by simply using extensions, not the filetype.

As @kugel- pointed out for C/C++ there are situations where actual combinations of files affect visibility, and in reverse just because a `.h` file is open in Geany does not mean all its symbols are available in another C/C++ file but they are considered for autocompletes for example.

This is the effect of the inability of the uctags/Geany to know about the build, without actual dependencies and following includes its simply not possible to do it correctly.

So its necessary to resort to heuristics, and they will never handle all situations. The decision needs to be made to find the most useful tradeoff between how many omitted visible symbols there are vs how many incorrectly visible symbols there are.

This was one of the reasons I moved to Vscode for C++ and I can sort of confirm the problem using Vscode because I notice that when I add another file to a project but before I add it to the build, Vscode (even using an LSP) will give a very similar excessive set of rubbish symbols to uctags/Geany.

@techee commented on this pull request.

• if (source_file->lang == TM_PARSER_C || source_file->lang == TM_PARSER_CPP)

+ { + const gchar **ext; + const gchar *common_src_exts[] = + {".c", ".C", ".cc", ".cp", ".cpp", ".cxx", ".c++", ".CPP", ".CXX", NULL}; + + for (ext = common_src_exts; *ext; ext++) + { + if (g_str_has_suffix(source_file->short_name, *ext)) + { + source_file->is_c_source = TRUE; + break; + } + } + } +

``` source_file->is_source = TRUE; ```

Yes, we could do that - makes probably more sense as the `is_source` flag is valid for all languages and not specific to C/C++.

```C if (source_file->lang == TM_PARSER_C || source_file->lang == TM_PARSER_CPP) { const gchar *ext = strrchr(source_file->short_name, '.');

if (! ext) source_file->is_source = FALSE; else { int i; const gchar *common_src_exts[] = {"c", "C", "cc", "cp", "cpp", "cxx", "c++", "CPP", "CXX"};

for (i = 0; i < G_N_ELEMENTS(common_src_exts); i++) { if (strcmp(ext + 1, common_src_exts[i]) == 0) break }

source_file->is_source = (i < G_N_ELEMENTS(common_src_exts)); } } ``` Does this code offer any benefit compared to what I wrote? I personally find my code a bit easier to read as you avoid the extra branch where `.` is not found and one also has to think a bit when looking at ``` source_file->is_source = (i < G_N_ELEMENTS(common_src_exts)); ``` what exactly it means.

Do you have some concrete examples of when including source files is used?

An example in one of the projects I'm currently doing has platform specific files included like:

```cpp #if defined(LIN) #include "plat_lin.cpp" #elif defined(WIN) #include "plat_win.cpp" #elif defined(MAC) #include "plat_mac.cpp" #endif ```

then the code that uses those in the including file. Other selective includes are the network code (using either Boost++ or cURL) and other libraries where there is more than one solution that can be wrapped to a consistent interface.

Its much neater than lots of `ifdef`s throughout the code.

@elextr interesting… I usually see this still using separate source compiled conditionally with a common header defining the interface. But OK, so you have a case where there is no way to know but having complete knowledge of the whole project tree -- which we won't have (well, a plugin like projectorganizer *could* look at all the files, figure out the includes and make a slightly more educated filtering guess, but it'd still be a heuristic without knowing the real build settings and all).

But I agree with @techee, the filtering is useful to lower the amount of irrelevant suggestions in most situations, so we have to find where to draw the line. Or we go the Geany way and add a setting? :smile:

Based on my following post `semi_random_guess_if_symbols_should_leak_everywhere` grin

Hmmm, maybe just simply `globally_visible`?

[Edit: oops, wrong way round, maybe `local_visibility`]

Actually if we want that to work for all languages, we could make it technical: `trust_file_scope` (which is really what this flags is about: whether we want to trust uctags' `isFileScope`)

@elextr no, that's what I though initially, but it's actually because of the `isFileScope` filtering. uctags sets it when it does *not* match a known header extension, which my file didn't. Here we're just taking the more conservative approach of setting it only if it *matches* a known *non-header* extension.

@elextr well, we do that only for C and C++ ATM (see code), but that's basically the reason why I suggest a generic name merely stating how the flag is used rather than what we try to achieve with it (which does not make sense for languages with no header/source separation)

Just to flesh out how C++ modules impact this.

Modules break the assumption that there must be a declaration in a header file for a symbol to be used in another file, the module is exported from a body file and the declarations from the modules are imported by an `import` statement, no header needed as the compiler does the work.

So if we set the filescope/local/whatever flag for `.cpp` files that will make the symbols exported with the module invisible elsewhere, but they should be visible.

Its not just an academic C++ exercise, since this is basically how modules work in most languages if we can solve it for C++ we can extend the heuristic to other languages too.

Just to flesh out how C++ modules impact this. […]

I'll look a tad into modules out of curiosity one day, but does that mean that a kind of header equivalent is generated by the compiler, so that it can be installed and imported?

I'll look a tad into modules out of curiosity one day, but does that mean that a kind of header equivalent is generated by the compiler, so that it can be installed and imported?

Presumably somewhere internal to compiler data files somewhere I guess ... oooh, that google is good https://gcc.gnu.org/wiki/cxx-modules#CMI_Location #3245

Just looking quickly at https://en.cppreference.com/w/cpp/language/modules suggests that there will be an export keyword, making things fairly easy for the C++ parser, doesn't it?

Yes, if for that declaration only having an "export" keyword it overrules the file long "local visibility only" ruling made from having a `.cpp` or equivalent extension.

@b4n I've just repushed a hybrid version of the patch - using the `trust_file_scope` name but using `g_str_has_suffix()` as I used in the original patch which I like a bit better (but I don't insist on that one too much if the other version is preferred).

Now the hard stuff - someone has to decide whether to merge this PR or https://github.com/geany/geany/pull/3457. I would lean towards merging this PR and if we start receiving bug reports related to this issue, we can revert to #3457.

I've been running the ever so slightly different implementation of this for a long while and it worked nicely for me. Just tested this PR again, and it seems to indeed actually behave the same, so I'm merging it.