[Geany-Devel] Plugins sharing resources

Matthew Brush mbrush at xxxxx
Wed Apr 10 00:17:14 UTC 2013

On 13-04-09 03:20 PM, WILLIAM FRASER wrote:
> On 06/04/2013, Lex Trotman <elextr at gmail.com> wrote:
>> On 6 April 2013 00:02, William Fraser <william.fraser at virgin.net> wrote:
>>> I attached an int to each scintilla object to keep track of what's been
>>> assigned in my markers plugin. The only problem was that some markers are
>>> used by scintilla, so any plugin would have to make note of which ones
>>> were
>>> being used by the editor (with the problem that you would have to update
>>> plugins if editor changed) or, you would have to submit code to scintilla
>>> so that it also used the uniform resource allocation.
>> Hi William,
>> Which plugin is that?  And how do you know that say the bookmarks plugin
>> isn't using that marker already?  Thats the sort of problem this is to
>> solve.
>> Cheers
>> Lex
> Hello Lex,
> It is the GeanyNumberedBookmarks plugin that has to manage sharing
> markers with other plugins and the editor. I had to re-write it as
> some of the markers were clashing with another plugin (I forget which
> one).
> The functions that handle keeping track of markers are
> GetMarkersUsed(), NextFreeMarker(), SetMarker(), and DeleteMarker().
> To get around the problem of different scintilla editor instances,
> each of which could have more than one document open in them, I used
> the g_object_set_data() and g_object_get_data() functions to attach a
> pointer to an allocated piece of memory holding data on which markers
> I'm using per Scintilla editor object (I see if there is one allocated
> already and if not add one, thus ensuring only one per editor
> instance). As there are 32 markers I used a 32 bit int to hold which
> markers were being used.
> Unfortunately it's a little more complex as other pluggins can also
> use the markers, as can the editor (some are documented as being in
> use:0 &1 for bookmarks & errors, 25 onwards for folds). So the
> NextFreeMarker() function in GeanyNumberedBookmarks thus only checks
> between 2 and 24 for free markers. I have assumed that anyone using a
> marker will likely set it to something other than the default of
> SC_MARK_CIRCLE, or at least followed documented good practice of
> resetting it to SC_MARK_AVAILABLE if they no longer need it. This is
> how I find unused markers.
> However there are potential problems with this due to the assumptions.
> Problems that could arise include: Markers being used by another
> plugin (or the editor if it's use of markers changes) after
> GeanyNumberedBookmarks has started using them without checking to see
> if they are already in use, and not setting the marker to something
> other than SC_MARK_CIRCLE.
> To get round these problem I can see only 3 options:
> 1) Each plugin manually setting their own markers as we do at the
> moment but with better co-ordination to avoid clashes, or to enable
> the user to set them manually in the pluggin settings. This is sort of
> what we have at the moment and is messy, and makes it difficult to
> maintain plugins, or develop new ones without clashing with existing
> plugins. It also has the downside of needing to check all pluggins if
> scintilla changes which markers it uses.
> 2) Submit a patch to Scintilla that adds functions similar to
> GetMarkersUsed(), NextFreeMarker(), SetMarker(), and DeleteMarker()
> that the editor, and any plugins would use. The downside of this is
> that they might not accept the patch, and that it would then mean that
> plugins using markers would only work with the version of Scintilla
> where the patch was accepted or later versions. It would be the
> neatest, and most robust solution.
> 3) Have plugin functions similar to GetMarkersUsed(),
> NextFreeMarker(), SetMarker(), and DeleteMarker() that any plugin has
> to call to use markers as part of the geany-plugins standard function
> calls. We would have to monitor Scintilla for changes to markers but
> would then mean that our plugins would play nicely with each other,
> and we could update/modify these functions independent of Scintilla.
> Also we would only have to changed the geany-plugins standard function
> if Scintilla's use of markers changed rather than having to re-write
> all the plugins. We also would not have to wait for any changes to
> Scintilla to propogate through the versions. This would probably be
> the fastest way of doing things.
> There is no reason why we could not use a combined approach: submit a
> patch to Scintilla and in the meantime have our own functions until
> the changes to Scintilla were adopted.
> Any plugins wide, or editor marker management functions would have to
> be thread safe to avoid clashes between plugins or the editor.

I don't think they'd need to be thread-safe, nothing else in Geany or 
the plugin API is.

> What do people think about these options? Does anyone have any other ideas?

Here's the ideas I was working on:

I still haven't tested it too much but I think the idea is pretty sound 
and flexible. It's quite like your #3 but a bit more generic and 
includes also a signal plugins can connect to in order to notify them 
when resources become available.

If you don't want to get bored reading the code, just jump to the /** 
doc-comments for descriptions of the functions.

P.S. The patch unnecessarily bumps the plugin ABI by mistake.

Matthew Brush

> William
> P.S. sorry for delay in getting back, and for not doing much with my
> pluggins of late, but life is beyond busy at the moment & for the
> foreseeable future.
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel

More information about the Devel mailing list