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
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
