[Geany-Devel] [FT-plugins] Proposed "Features"
mbrush at xxxxx
Thu Sep 1 05:47:08 UTC 2016
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
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.
More information about the Devel