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

Matthew Brush mbrush at xxxxx
Tue Aug 30 16:41:28 UTC 2016


On 2016-08-30 08:51 AM, Thomas Martitz wrote:
> 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.
>

I've tinkered with implementations, it's generally as easy as walking a 
list in a loop, calling a function and breaking early if the function 
returns `FALSE`.

I don't think I claimed it will be a massive change, I think I just said 
it will add more complexity to ft-plugins, as opposed to less, as you 
claimed.

Since the very first response I made to you about TM, I've been open to 
the idea. I raised a few concerns which you never responded to, namely 
that it may not be possible for TM to handle all the tags in Clang's AST 
(it has a very rich and complex AST, heavily optimized by some of the 
smartest people in the C++ world). Also the AST is HUGE and representing 
it twice in memory would at least (if not more than) double the memory 
footprint.

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

I never said I proposed a design on IRC, that's what the "Proposed 
Design" email was about. I discussed approaches and details with some of 
the developers. You and I talked about whether TM might be up to the job 
of representing scope, for example (and you pointed out that it can, 
crudely, by using strings rather than parent/child relationships).

> Your evaluation is still invisible to me.
>

I evaluated the various approaches myself and by discussing specific 
topics with some devs lately and previously when we talked about 
ft-plugins so that I would be able to propose a design on the mailing 
list, and here we are discussing that. I don't see the problem.

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

Unrelated to whether to use TM or not, I think you're right that a hook 
to tell ft-plugins to re-parse would be useful, otherwise plugins will 
all have to implement that logic/signal connections themselves.

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

I think you underestimate how many tags we're talking here. The example 
libclang ft-plugin would have to re-walk the entire AST (which is 
absolutely massive, particularly for C++), convert it to TM tag 
structures, and then Geany/TM would have to perform some merging logic, 
would would be more complicated than now if it was to support C++ 
properly, every single re-parse. My intuition tells me that just won't 
be fast enough, Clang already jumps through hoops and uses tricks to 
just build its own AST in-time.

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

I have tried that, I can try and find the code if I still have it. The 
problem I have with it is that it adds a whole other framework (ILexer) 
and language (C++) that has to be used, and it's a lot more involved 
just to perform basically the same task. In both cases ft-plugins could 
either provide their own states or re-use those from an existing lexer 
built-into Geany, so I don't think container vs dynamic lexer will have 
any bearing on the inconsistency of colour schemes.

Cheers,
Matthew Brush



More information about the Devel mailing list