My reason behind using simply a wxArrayString (and, now that I think about it, it could just be a wxString, because the next step would be to concatenate it anyway) is that a CC plugin would register the icons it wants, and just embed those values in the returned string(s).
Alternatively, should the main app be responsible for registration?
IMHO, that's a bad idea because using strings as a container object and marshalling, demarshalling necessary information is absurd.
I am sure there will be more information that needs to be conveyed than a simple string. First thing that comes to mind is
displayed vs inserted text. For example the code completion result for function
int foo (int param) you can display it in the
completion list as
foo(int):int or any variation thereof but you only need to insert the
foo (maybe with parentheses)
also there is other information that I've mentioned before. I am sure you are not proposing to embed all this information in one string
which is very hard to use. Some data structures like the ones obfuscated gave examples of and I've mentioned are absolutely necessary.
Active editor, because I can think of no circumstance in which one would want autocompletion on a non-active editor. Passing a filename or cbEditor* would, in my opinion, be an unnecessary level of indirection.
Yeah, probably but, IsProviderFor() needs it anyway so there is no need to be stingy. Thing is it can help decouple the CC plugin from the Manager to some extent and
because singletons are evil
and there is an attempt in this direction(discussed
http://forums.codeblocks.org/index.php/topic,17750.0.html). Also every method that is using active editor need boilerplate code something like this;
cbEditor* editor = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
if (!editor)
return;
if (IsProviderFor(editor))
{
//Do stuff probably involving further indirection to cbStyledTextCtrl.
}
Pass a viable and healthy editor and save the plugin developer from some suffering.