Hi all!
But splitting the plugins further won't fix the problem. Thinking about it, the best solution would be to put the configuration in some other plugin, maybe the editor plugin (as it already provides means for code completion). What do the others think?Good Idea! But what will we do, if a language-support plugin won't support some options? Should we hide this option from the user, if this plugin is activated?
That's a tricky problem. Python and C are quite different to indent so I assume we won't be able to do this with a single preference dialog. And it's not clear if all users really want the same settings for C and Python, some projects use quite different settings there.
I'm not sure what you mean here. Do you want to have a plugin for completion that will use one of the parser plugins to do the completion?
"Parser" is probably a big word for the things that could be shared between plugins. There are some things that happen in every plugin though: 1 Some trigger to start completion (e.g., slow typing, ".", "->", etc.) 2 Parse the context and show completions (async operation) 3 Update completions while typing continues and eventuell hide them on choice or on another trigger (e.g. space). 1 and 3 is basically the same in every plugin with the exception of different triggers. Those should probably be in the editor or a general assistance plugin, 2 is quite different. The advantage of seperating the parser plugin for C is that we can choose to use ctags or clang for parsing. For vala is might be better to just implement both, IAnjutaLanguageSupport and IAnjutaParser in the same plugin. @Moritz: Remember your weekly reports... Regards, Johannes
Attachment:
signature.asc
Description: This is a digitally signed message part