On Tue, 10 Jun 2008 15:09:41 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 10 Jun 2008 13:10:30 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
...
- Make header names consistent - I've used ui_utils.h,
plugin-symbols.c - probably they should just be uiutils.h, pluginsymbols.c.
I'm not sure. We could rename the plugin-symbols.c but do we need to rename ui_utils.h? I personally like the underscore because it is more readable than without even if it is a little harder to type.
OK, so what should be the default naming style - we already have sciwrappers.h and recently documentprivate.h - should these also have underscores? Or maybe it doesn't matter?
- Make editor functions take a GeanyEditor struct pointer. The
editor fields of GeanyDocument could be moved into a separate struct, as the document struct is quite big, making it harder to locate fields. This is also good for an object-based design.
I agree.
Great, I'll probably do this after I start (3).
- The document functions could take/return a GeanyDocument pointer
instead of a document index, which would avoid the use of: documents[idx]-> being repeated all over the code base when doc-> is much neater. We would also need to update functions like msgwin_msg_add which take a idx parameter (this seems to be the only one at first glance).
I forgot to say, it would also mean much neater checks for an invalid document, just doc != NULL instead of DOC_IDX_VALID(idx) in most cases after using p_document->get_current().
Yeah, that's the killer argument ;-). I like the idea even if it is a lot of work.
This could be quite a big change, so it could be brought in gradually by having an additional p_documents field in GeanyFunctions, using a documents_ prefix for the new functions instead of document_. Once the changes are complete we could deprecate the old ones.
Don't know if it is worth. I don't mind if the SVN version is broken for the one or another day. It's a development version and users should expect it to be broken.
I think it can be done without breaking things - my first goal is to update the plugin API, so the core would be unaffected at first. I'll add a private Document::index field and then wrap the adapted document functions (which would use documents_) with the old document_ functions and idx usage. Then I'll update the core to use the new functions.
I'd thought maybe we could rename document.[hc] documents.[hc] - or would you prefer not to? I'm not sure but it might be more consistent with filetypes.c, using the plural rather than singular.
Regards, Nick