[Geany-Devel] [FT-plugins] Proposed "Features"

[Matthew Brush]

On 2016-08-29 03:17 PM, Thomas Martitz wrote:
> Am 29.08.2016 um 17:05 schrieb Jiří Techet:
>> [...]
>
> There is also another aspect about the proposal that worries me: a
> plugin shall provide N features for M languages. And X plugins might be
> compete (not even considering the desire that plugins can build upon
> each other). This means (slightly exaggerated) that N*M*X possibilities
> have to be managed by Geany's conflict resolution. I don't want to
> implement that. It seems much simpler to me to collect tags from
> plugins, merge them (maybe throw out duplicates) and pass them to the
> actual feature code all within Geany.
>

In principle it's not that hard to manage, as mentioned in my "Proposed 
Design" message, Geany just needs to keep the providers in a list and 
the callbacks work like GTK/GDK callbacks (and some in Geany) where the 
callback's return value determines whether the next provider is called 
or not. In that message I attached a mockup of a kind of UI that could 
be used to allow users absolute control, and for Geany it's just a (set 
of) ordered lists.

> What worries me is that we jumped from mere brainstorming to a
> relatively concrete proposal, without evaluating requirements or any
> other research. Or was this evaluation just invisible to me?
>

I evaluated and experimented with several different approaches and 
discussed various details with some of the main developers (including 
you) on IRC. Based on the way that in my opinion, as someone who has 
tried and failed to implement the needed features in the past, and as a 
Geany developer, I recommended a proposed design for further input. And 
here we are :)

As I asked in an earlier message, I'd be interested if you could provide 
some more concrete examples of what you were thinking with using TM, 
which would accomplish the goals mentioned in the Github Issue and 
fleshed-out more in the top of this thread.

Cheers,
Matthew Brush