Thank you for your reply.
It is only not a waste of time for me if we agree that the proposed function may be accepted. As I have written. Exactly because my offered contribution is not the top in my priority list, it is important to avoid wasting time whenever possible. Of course I know there is no guaranty for an acceptance, but if there is not an agreement at the start it is a waste of time to create a pull request and then just to get the answer "no it is not what i meant". The proposed modification is not a big thing and I agree to you that the existing functionality should not be effected. Therefore the extended proposal with the checkboxes: they do exactly that. If they are set (which will be the default) the behaviour is exactly like it is now. My original idea was not to get too many found "errors" because the pattern matching for the compilers output is implemented additive and not only what is specified in the option settings for the regular expressions. This behaviour could be controlled by the check boxes.
And BTW: our positions for this small modfication are not as far away from each other than it may look like.
The replacement plugin is something more than the proposed extension here: it shows errors and warnings separated in a tree structure where the sometimes long error output of the compiler can be folded, the entries can be clicked to jump to the error/warning location (same like the integrated built function), line indicators as now mark the exact line in the window (also the same like now). This is already working in the current state. What is left to implement: all global and project specific settings and maybe some menu.