<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 30, 2016 at 6:41 PM, Matthew Brush <span dir="ltr"><<a href="mailto:mbrush@codebrainz.ca" target="_blank">mbrush@codebrainz.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2016-08-30 08:51 AM, Thomas Martitz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 30.08.2016 um 01:53 schrieb Matthew Brush:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2016-08-29 03:17 PM, Thomas Martitz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 29.08.2016 um 17:05 schrieb Jiří Techet:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[...]<br>
</blockquote>
<br>
There is also another aspect about the proposal that worries me: a<br>
plugin shall provide N features for M languages. And X plugins might be<br>
compete (not even considering the desire that plugins can build upon<br>
each other). This means (slightly exaggerated) that N*M*X possibilities<br>
have to be managed by Geany's conflict resolution. I don't want to<br>
implement that. It seems much simpler to me to collect tags from<br>
plugins, merge them (maybe throw out duplicates) and pass them to the<br>
actual feature code all within Geany.<br>
<br>
</blockquote>
<br>
In principle it's not that hard to manage, as mentioned in my<br>
"Proposed Design" message, Geany just needs to keep the providers in a<br>
list and the callbacks work like GTK/GDK callbacks (and some in Geany)<br>
where the callback's return value determines whether the next provider<br>
is called or not. In that message I attached a mockup of a kind of UI<br>
that could be used to allow users absolute control, and for Geany it's<br>
just a (set of) ordered lists.<br>
</blockquote>
<br>
You say this should be easy, I say I expect it to be complicated. This<br>
is quite the same (just the other way around) with my suggestion to just<br>
pass tags to Geany. There you keep claiming that it'll be a massive<br>
change why I expect it to be relatively easy to do. At least not harder<br>
than changing 6+ core parts in Geany to execute plugin callbacks and<br>
make something useful from the results.<br>
<br>
</blockquote>
<br></div></div>
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`.<br>
<br>
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.<br>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What worries me is that we jumped from mere brainstorming to a<br>
relatively concrete proposal, without evaluating requirements or any<br>
other research. Or was this evaluation just invisible to me?<br>
<br>
</blockquote>
<br>
I evaluated and experimented with several different approaches and<br>
discussed various details with some of the main developers (including<br>
you) on IRC. Based on the way that in my opinion, as someone who has<br>
tried and failed to implement the needed features in the past, and as<br>
a Geany developer, I recommended a proposed design for further input.<br>
And here we are :)<br>
</blockquote>
<br>
<br>
Please show me the point in the IRC logs where I agreed with your<br>
approach. In fact, I can't remember discussing ft-plugins with you on<br>
IRC at all (I just asked at one point how libclang works in more detail).<br>
<br>
</blockquote>
<br></span>
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).<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Your evaluation is still invisible to me.<br>
<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As I asked in an earlier message, I'd be interested if you could<br>
provide some more concrete examples of what you were thinking with<br>
using TM, which would accomplish the goals mentioned in the Github<br>
Issue and fleshed-out more in the top of this thread.<br>
</blockquote>
<br>
<br>
Essentially I'd propose a signal that's emitted when Geany begins<br>
(re-)parsing a file (I believe it does this after each keystroke, after<br>
a debouncing timeout). Plugins could connect to that signal, perhaps<br>
parse the file again, using their special, language specific library<br>
code, and pass the tags they've got to Geany using a to-be-designed API<br>
function (probably involving TMTag and TMSourceFile). Alternatively, the<br>
plugin signal handlers could run before Geany's own one, potentially<br>
blocking Geany from parsing the file at all. Or both approaches.<br>
<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Geany would then merge the tags, perhaps giving the plugin ones more<br>
weight, and store it in TM.<br>
<br>
</blockquote>
<br></span>
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.</blockquote><div><br></div><div>I think it would be a disaster performance-wise. The number of AST nodes can be easily 100x more than the amount of tags we have from ctags (we get a single tag for a function now and AST will contain complete tree for the function body) so just this might cost 100x more. In addition all the necessary copies to TM internal representation, having to maintain the tree structure (in TM we use GPtrArrays for everything which are very efficient and during tag merge we try to eliminate even pointer dereferences because those start getting expensive when managing many tags) etc.</div><div><br></div><div>And even if we did this, I don't know how we could handle ASTs of different languages in a generic way because these will differ significantly.</div><div><br></div><div>Anyway, if needed we can always add more elements to the TMTag structure so plugins can add some more information.</div><div><br></div><div>Cheers,</div><div><br></div><div>Jiri</div><div><br></div><div> </div></div></div></div>