Plugins for C/C++ development
Submitted by Sunday, 15 October, 2006 - 13:49
on
I intend to add a few features to jEdit for C/C++ developers, such as a class hierarchy browser and a static function call tree. These features will be based on ctags and either cscope or GNU global.
I'd like to discuss here the plugin distribution methodology. We already have several plugins using ctags - Jump!, Tags, CodeBrowser, CtagsSideKick. Each of them parses the ctags output on its own and handles the storage of the data by itself. I think it's better to have a common library plugin to handle the interface with ctags - both invocation, parsing and storage. There are several advantages to this other than avoiding duplication of code:
- The data can be shared (when appropriate) between plugins that use ctags, so there is no need to run ctags a couple of times on the same file with the same flags.
- The configuration of ctags (e.g. per-mode configuration) can be done in a single place, the plugins that use it (usually) don't even need to be aware of it.
- It will also be easier to write new plugins using ctags.
While a library plugin for ctags seems reasonable, there's the other problem of what I call "plugin explotion": The list of installed plugins becomes long, with all consequences (including the one that's most annoying for me - the jEdit Plugins menu gets split, e.g A-G,H-Z...).
Do you think all ctags-related plugins should be combined into one? What about new features like those I mentioned above - should they be put into new plugins or inserted into existing plugins?
A good example can be taken from eclipse - which is normally installed with hundreds of plugins. Unlike jEdit, eclipse does not have a 'Plugins' menu. Rather, each plugin inserts itself in the desired places (e.g. toolbar, menu item, options). In contrast with jEdit, eclipse consists almost entirely of plugins. A pure eclipse with no plugins can't do much (if anything at all).
Please let me know what you think. Thanks!
I'd like to discuss here the plugin distribution methodology. We already have several plugins using ctags - Jump!, Tags, CodeBrowser, CtagsSideKick. Each of them parses the ctags output on its own and handles the storage of the data by itself. I think it's better to have a common library plugin to handle the interface with ctags - both invocation, parsing and storage. There are several advantages to this other than avoiding duplication of code:
- The data can be shared (when appropriate) between plugins that use ctags, so there is no need to run ctags a couple of times on the same file with the same flags.
- The configuration of ctags (e.g. per-mode configuration) can be done in a single place, the plugins that use it (usually) don't even need to be aware of it.
- It will also be easier to write new plugins using ctags.
While a library plugin for ctags seems reasonable, there's the other problem of what I call "plugin explotion": The list of installed plugins becomes long, with all consequences (including the one that's most annoying for me - the jEdit Plugins menu gets split, e.g A-G,H-Z...).
Do you think all ctags-related plugins should be combined into one? What about new features like those I mentioned above - should they be put into new plugins or inserted into existing plugins?
A good example can be taken from eclipse - which is normally installed with hundreds of plugins. Unlike jEdit, eclipse does not have a 'Plugins' menu. Rather, each plugin inserts itself in the desired places (e.g. toolbar, menu item, options). In contrast with jEdit, eclipse consists almost entirely of plugins. A pure eclipse with no plugins can't do much (if anything at all).
Please let me know what you think. Thanks!