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

[Thomas Martitz]

Am 30.08.2016 um 01:53 schrieb 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.

You say this should be easy, I say I expect it to be complicated. This 
is quite the same (just the other way around) with my suggestion to just 
pass tags to Geany. There you keep claiming that it'll be a massive 
change why I expect it to be relatively easy to do. At least not harder 
than changing 6+ core parts in Geany to execute plugin callbacks and 
make something useful from the results.

>
>> 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 :)


Please show me the point in the IRC logs where I agreed with your 
approach. In fact, I can't remember discussing ft-plugins with you on 
IRC at all (I just asked at one point how libclang works in more detail).

Your evaluation is still invisible to me.

>
> 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.


Essentially I'd propose a signal that's emitted when Geany begins 
(re-)parsing a file (I believe it does this after each keystroke, after 
a debouncing timeout). Plugins could connect to that signal, perhaps 
parse the file again, using their special, language specific library 
code, and pass the tags they've got to Geany using a to-be-designed API 
function (probably involving TMTag and TMSourceFile). Alternatively, the 
plugin signal handlers could run before Geany's own one, potentially 
blocking Geany from parsing the file at all. Or both approaches.

Geany would then merge the tags, perhaps giving the plugin ones more 
weight, and store it in TM.

Then the symbol tree, completion, other plugins can use the tags and 
make their stuff.

For highlighting, I would really try to use Scintilla dynamic lexers. 
Otherwise we're going to have trouble with inconsistent editor widgets 
and non-working color schemes.

Best regards