Am 01.09.2016 um 08:05 schrieb Lex Trotman:
On 1 September 2016 at 15:08, Thomas Martitz kugel@rockbox.org wrote:
Am 31.08.2016 um 17:26 schrieb Lex Trotman:
I think we all agree that help of language-specific plugins is desired/required. No need to restate "we need language specific support" all the time.
We just disagree on how the language-specific knowledge is transported to Geany, other plugins and the user.
Well, I read your previous comments such as "But *just* the data, don't offload very specific use cases onto them" (and to some extent this one too) as saying that all the plugin has to do is return some data (tags) and Geany will take it from there and all I was doing was making sure it was clear that its unlikely that Geany will be able to "take it from there" in any meaningful way, based purely on data, without filetype specific knowledge inside Geany.
Here we disagree. I think it is possible to extent TM/Geany sufficiently to encode this information in generic ways. As an example, template instantiation yields different types. TM could tread them as different types. Any variable will be of one of the types, so calltips would just work.
It is of course always "possible", after all its a mere matter of programming :)
And of course an instantiated class template is just a type, but what is the name of std::vector<int> and std::vector<A> so it can be looked up?
vector<int> and vector<A>, with scope being std (I think trailing scope delimiters are not saved in the scope string of TMTag, just intermediate ones).
Geany must ask the plugin for the answer for each element of functionality the plugin provides. This means that those elements have indeed simply moved "Geany's deficiencies to the plugin space" as you put it. This is good and necessary.
To me this is not good because it makes it impossible to use the information for other use cases in Geany or other plugins.
For example, I want to keep my quickswitch plugin that allows me to jump to arbitrary tags, even if a ft-plugin is doing all the hard work to parse them.
Good point, the FT-Plugin API needs functions for goto declaration and goto definition. Unlike TM, the plugin can take language and scope rules into account when it answers, so you get the right declaration, continuing the theme above, where would you go to find the declaration of std::vector<int> ?
Certainly not the line:
std::vector<int> list_of_ints;
thats the declaration of `list_of_ints` but thats the only place that `std::vector<int>` exists in the code.
Ideally the header which defines std::vector<A> would be found (and maybe opened) right? Currently this isn't possible with TMTag (as var_type can only contain either vector<A> or vector<int>) but it shouldn't be too hard to make it work. Like adding a generic_type field which is set for each template instance (containing vector<A>), then instead of looking up the decl of generic_type if it's not NULL, otherwise var_type.
Of course, the TMTags associated with vector<A> and vector<int> would have to provided by the ft-plugin too (maybe there needs to be a new TMTagType for vector<A> too).
Of course moving the problem to plugin space doesn't mean the plugin can't use Geany facilities where their capabilities fit the requirement. But we should not try to expand Geany to handle all types of functionality.
Like your TM query interface, the plugins should answer the questions like "whats the autocomplete here", "what calltips are relevant here" with a flat list of data relevant to the question.
My TM query interface wants to return all matching tags, including those found by ft-plugins. Can this be done?
Only if your query plugin queries the FT plugin.
So that means
1) My plugin contains code specifically for each known ft-plugin (i.e. not the plugin API) 2) There needs to be a shared library which my plugin can use to call into the other plugin 3) My plugin needs to know if and when to ask a ft-plugin
This is not acceptable. Or are you saying Geany could provide a wrapper for this as Matthew suggested? That might be workable.
Best regards.