geany 1.36 from gentoo portage tree. When I try to open C source/header, it freezes for nearly half-minute on first such attempt. Next C file attempts go without freeze. Tried with all modules disabled. Build config (guessed from ebuild): --enable-gtk3 --enable-vte --disable-html-docs --disable-pdf-docs
My current tags database has over 2k files, which look like matching to C header files, with total size over 400Mb. On first attempt to open C source/header (but not on editor start) it loads all of them (can be visible if started with --verbose option). It doesn't matter if this file empty or just config.h, generateed by build system.
Would be better if only necessary files where loaded, based on include/import lines in opened file, recursively. Could be less annoying if geany never needed to be closed/restarted.
Your analysis is correct as far as it goes, yes Geany loads _all_ the tags related to the language of the file being opened as soon as the first file of that language is opened.
This is because there is no way of knowing which tags to load, the tags files have nothing to indicate which includes they came from, and even if that was known, includes in the file being opened typically include includes recursively so Geany would have to recursively open all include files to find which tags to load, and even that can't be done with C because Geany has no knowledge of the include directories that are searched (the `-Ixxxx` options to the compiler commands).
Geany itself provides five language specific tags for a total of 1Mb and the C language one being 60kb.
If the tags are installed by the Gentoo package I would suggest you need to discuss with them that they may be being a little _too_ helpful :grin:
If you installed all the tags, then if you use all those libraries in the files you work with, you are stuck, first opening will be slow, but as you noted all successive openings are fast.
Or if you don't need them all, you might rename or delete some to improve performance.
Note that for different projects you can build different configuration directories which can have different sets of tag files included (and since this is Linux you can use hard links to save space for tag files that are used in many places).
I had in mind 3 possible improvements for tag loading: 1. Load on demand only those tag files, whose target files/modules have path ending with string from include/import line. E.g., C include line <sys/types.h> would involve tag files for all headers, whose paths end with "sys/types.h". Of course, if same file presents in multiple dirs, their all tag files would be loaded. 2. Show loading progress. I would never understand what caused such lockdown if did not run geany with --verbose. Progress could be measured in number of involved tag files for current load operation. 3. Parallel load in background, without blocking editor. Ideally this could be also used to load more files when new include/import line added. This time progress would appear in statusbar.
Your three improvements are of course possible with enough programming, but some of the pitfalls are:
1. would require some way of associating `#include <sys/tags.h>` with a specific tag file, tag files do not have the paths of the files they come from in the names, and even if they did Geany does not recognise `include`, `import`, `using` or whatever other instruction the language uses. Of course if the source (the `sys/tags.h`) was in the tag file contents then the tags files have to be read to find it, so might just as well be loaded anyway, and of course the solution has to work for languages that are not C as well. Loading all tags associated with a specific language, as used now, is the only way thats common to all languages.
2. showing loading progress would require knowing how many tags are going to be loaded, so the progress can be measured, but the number of tags in a file isn't available until its loaded, which is kind of too late. It would be possible to count files as a very rough guide, pull requests are welcome.
3. the tagmanager code (in fact all Geany code) is not re-entrant so either it would have to block the front end from accessing symbols while the tags load, which would not be much of an improvement, or finer grained locking would need to be added which would slow down both the front end and the background access and would require a great deal of careful work to not include races or deadlocks.
As I said its just a MMof lotsOP and somebodys got to do it, pull requests are welcome but due to the likely complexity may take considerable time to be accepted.
Or if you only want to do a C specific capability you possibly could make a plugin that read and recognised the `#include`s and loaded specific tags from a directory Geany doesn't know about. I think all the relevant functionality is in the plugin API, or could be added with suitable pull requests.
github-comments@lists.geany.org