[Geany-devel] API: headers / GeanyEditor / gint idx

[Nick Treleaven]

On Tue, 10 Jun 2008 15:09:41 +0200
Enrico Tröger <enrico.troeger at uvena.de> wrote:

> On Tue, 10 Jun 2008 13:10:30 +0100, Nick Treleaven
> <nick.treleaven at btinternet.com> wrote:
...
> > 1. 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?

> > 2. 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).

> > 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