[Geany-Devel] Plugins sharing resources

[WILLIAM FRASER]

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.

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

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.