KDevelop syntax parser is barely usable

[René J.V. Bertin]

On Tuesday November 13 2018 10:55:47 Steve the Fiddle wrote:
>paths" (as René suggested). I'm still not sure that I really understand how
>to use these properly, and the manual is rather sparse about this feature.

Don't blame the manual, blame the people who're not trying to keep it complete ;)

The idea with "these" is simple. You shouldn't need them with cmake or qmake-based projects, but when your project is based on a Makefile you need to copy all non-standard header include files set in Makefile(s) and those preprocessor macros that are not set via a header file (config.h often).

>Setting this up was extremely time consuming because it takes so long to
>re-parse the project before the effect of the changes can be seen.

The trick there is to take it 1 file at a time; the Problem toolview has a reload/update button you can use to reparse just that file. Deactivate the full project parse feature or the "reparse project after changing" (in the defines/include paths settings dialog) so that you don't trigger a full reparse accidentally.

I find that disabling automatic full parsing at project load works well enough for me. Files are parsed when you open them, which includes all the headerfiles they include. So when file1.cpp from a project refers to a function from libfile2.cpp of that same project I will probably only get direct access to the function declaration from libfile2.h *at first*, but from there I can use a shortcut to open libfile2.cpp which will then be parsed. In the end I'll have a parse database representing only the parts of the project that are relevant to me. Even with audacity that can make a considerable difference.
FWIW, I also reduce the number of background parser threads to 2 at the most (I have only 4 cores in my system) because otherwise I find I have too little foreground reactivity left once the parser kicks in. 

Cheers,
R.