This indicates that TMTag is GBoxed-derived, and can be copied/ref'd.
This helps plugins that must store a tag pointer for later usage while the tagmanager might let it go in the meantime (can happen quickly if the user comments a function out when starting a doxygen-comment). You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1465
-- Commit Summary --
* api: export tm_tag_get_type()
-- File Changes --
M doc/Doxyfile.in (1) M src/tagmanager/tm_tag.c (6) M src/tagmanager/tm_tag.h (5)
-- Patch Links --
https://github.com/geany/geany/pull/1465.patch https://github.com/geany/geany/pull/1465.diff
kugel- commented on this pull request.
@@ -798,6 +798,7 @@ INPUT = @top_srcdir@/src/ \
@top_srcdir@/src/tagmanager/tm_source_file.h \ @top_srcdir@/src/tagmanager/tm_workspace.c \ @top_srcdir@/src/tagmanager/tm_workspace.h \ + @top_srcdir@/src/tagmanager/tm_tag.c \
FYI, this is so that the function also lands in geany-gtkdoc.h
I need this for a plugin I'm developing (peasy-based but this is also useful for C plugins).
@b4n Can you please take a look here? You said on IRC that it's probably OK
b4n commented on this pull request.
This looks good, and useful. However, which impact does it have on performance for dynamic languages which would likely always ref/unref through the `GBoxed` API, even when not actually needed. Or are Python and other GType bridges smarter than that and only copying when really required?
@@ -82,7 +82,11 @@ typedef struct
gboolean first; } TMSortOptions;
-/* Gets the GType for a TMTag */ +/** Gets the GBoxed-derived GType for a TMTag.
Should we advertise it's derived from GBoxed? C code should probably have access to `tm_tag_ref()`/`tm_tag_unref()` instead as it has more meaningful semantics as `g_boxed_copy()`, and generic code can figure it out by itself looking at the type information. And advertising GBoxed means it's kind of stuck to that implementation -- which is likely to say indeed, so I'm probably nitpicking, but we could want to change that one day.
Anyway, that's not a so important point.
@@ -82,7 +82,11 @@ typedef struct
gboolean first; } TMSortOptions;
-/* Gets the GType for a TMTag */ +/** Gets the GBoxed-derived GType for a TMTag. + * + * @return TMTag type + * @since 1.31 (API 232) */
unfortunately that probably will have to be updated
kugel- commented on this pull request.
@@ -82,7 +82,11 @@ typedef struct
gboolean first; } TMSortOptions;
-/* Gets the GType for a TMTag */ +/** Gets the GBoxed-derived GType for a TMTag.
I followed the same procedure as for TMSourceFile where this was accepted. I'm telling it's a GBoxed so that you you know can use g_boxed_copy/free, since the ref/unref functions are not exported.
I have no problem with exporting ref/unref (and maybe removing the GBoxed reference from the comment) if you prefer.
The performance question is kind of moot, since you can't use TMTag safely without this patch. Functionality comes first :-)
But reference counting is pretty cheap isn't it?
kugel- commented on this pull request.
@@ -82,7 +82,11 @@ typedef struct
gboolean first; } TMSortOptions;
-/* Gets the GType for a TMTag */ +/** Gets the GBoxed-derived GType for a TMTag. + * + * @return TMTag type + * @since 1.31 (API 232) */
Do you mean because this won't make it for 1.32?
Closed #1465 via 169feae90e72d54049c7765c6975fa9a009268aa.
Fixed the trivial issues and merged.
github-comments@lists.geany.org