If we enable them by default, there is no point for them being contrib plugins. We could as well move them to the other folder then.
That's not entirely true.
However, there may be people who don't want contrib plugins at all, or only a subset of them.
--disable-contrib for them.
I bet most people want then
compiled. A poll could resolve what should be the default.
Especially since you are someone who experiences quite long loading times, you should actually have had a thought about removing a few things that you never use.
That commentary is really out of place. Changing the default value for a configure flag doesn't have anything to do with loading times, since you can disable the plugins loading from within C::B.
For example, I regularly compile wxSmith and Help by hand because those are the only contrib plugins I ever use.
I for one, preffer to compile all plugins, and later at run-time, choose the ones I use most often.
Do you have any other short-term solution for KirkD, MortenMacFly, and other linux users?
I mean, we're already compiling and distributing contrib plugins in Windows for both stable and nightly builds.
Clearing the issue: for a long-term solution, of course the contrib plugins will be probably removed, because when C::B will have a big quantity of plugins made (like Eclipse) it will be the right time, but just now we have a reasonable small quantity of plugins.
Probably in the future even the contrib plugins will have to be sorted out of the codebase repository, moved to their own plugins repositories and mantained independently, downloaded trough the new codepacks
Again, I'm only talking about a short/medium-term solution, that is changing the configure default option, without forcing anyone, with the intentions of making it a little bit easier for the linux users.