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

[Matthew Brush]

On 2016-08-31 10:08 PM, Thomas Martitz 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.
>

Let's use the simplest C example:

     gint x = g_...

Please describe the algorithm (just in prose) that would give only the 
valid completions (ie. would compile in a C compiler) for `g_...` 
without providing any impossible completions, and without knowing 
anything about C/C++/Obj-C.

>> [...]
>
> My TM query interface wants to return all matching tags, including those
> found by ft-plugins. Can this be done?
>

There's no reason an API couldn't be provided to query such information 
even from ft-plugins, for ex.

    void query_symbols(criteria, out_tags_list);

Geany doesn't have to know every tag in order to call into ft-plugins 
for such query results, and can even fallback to TM/ctags if no plugins 
support this feature.

Cheers,
Matthew Brush