[Geany-Devel] Segmentation fault when auto-close plug-in is enable [patch]

Lex Trotman elextr at xxxxx
Thu Oct 24 03:39:04 UTC 2013

On 24 October 2013 13:09, Matthew Brush <mbrush at codebrainz.ca> wrote:

> On 13-10-23 11:36 AM, Thomas Martitz wrote:
>> [snip]
> Regarding that pattern we discussed previously and used in this AutoClose
> code for attaching data to a document, I'd be interested whether you or
> anyone thinks this branch (last/top two commits) would be useful to plugins:
> https://github.com/codebrainz/**geany/commits/document-**datalist<https://github.com/codebrainz/geany/commits/document-datalist>
IIUC several plugins already use various methods of storing data for
different documents and other Geany data structures.  Having a common way
of doing that which cleans up when the Geany struct is destroyed is a good

But it seems a pity to have to duplicate the glib interface for each
structure that offers the facility, can we just return the GData and let
the plugins use the normal g_datalist functions?

> IMO it'd be better to make GeanyDocument an actual GObject and get the
> data lists for "free", but at least this is sort of a step in the same
> direction.
> Disclaimer: I have no interest in "defending" this or hashing it out, it's
> just one of my many local branches and hasn't been really tested. If anyone
> doesn't like it, or spots some bugs or something, they can just not saying
> anything (ie. I'm not asking for Code Review) and it will quietly go away,
> if anyone really likes it, they can push it forward and we can review and
> discuss it at that point.
Don't try to make special conditions that say your contributions must not
be discussed/reviewed, thats rude, its like saying you think you are better
than the other contributors on this list.


PS On the recycling of doc structures and doc->is_valid, this does have the
advantage (for a structure where miscellaneous pointers to the structure
are going to exist in Geany and plugins) that doc pointers will always
point to a geanydocument struct.  So the is_valid test is always right.  If
the memory was returned and re-cycled into some other struct, the old doc
pointers could point to anything, and could just as easily appear a valid
document.  So its safer than the alternative, but the requirement to check
is_valid really does need more visibility since its an unusual idiom.

> Matthew Brush
> ______________________________**_________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-**bin/mailman/listinfo/devel<https://lists.geany.org/cgi-bin/mailman/listinfo/devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20131024/6bb1000f/attachment-0001.html>

More information about the Devel mailing list