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

Lex Trotman elextr at xxxxx
Mon Aug 29 12:23:37 UTC 2016

> This adds per use case hooks to plugins, which then became part of the stable API. I don't think that we have to codify every single use case of tags into the plugins. That's just making it harder (maybe impossible?) to change or add use cases.

The point of this proposal is to change and add use-cases that are not
currently possible with the current plugin API.  But instead of each
use-case generating its own piece of API and its own infrastructure,
the point of the FT-plugins proposal is to provide a common
infrastructure and approach for all filetype specific use-cases, those
needed for currently suggested uses, indentation, clang based styling
and symbols, and as framework for future use-cases we either havn't
thought of, or havn't a concrete intention to add immediately.

> I thought we agreed that plugin should simply provide tags to Geany/TM

This proposal is about many types of filetype specific functionality,
not just tags.  Tagmanager will not help in any way with indenting
Haskell, or even C++.

>  I'd rather not mix highlighting in this TM-related topics.

It appears you have misunderstood the purpose of the proposal, or I have.

It is my understanding that, as noted above, the proposal is to allow
plugins to provide filetype specific capabilities for many areas,
"features" in Matthews parlance.  Its not intending to change the
existing plugin API but to extend it to support functionality that
cannot be performed at the moment.

An example is Matthews attempt at using libclang in a plugin, which
provides, highlighting, symbol lookups, formatting etc with much
greater accuracy than the existing facilities in Geany can do.  But at
the moment there is no facility in Geany for any of that that
information to be injected for any filetype, or without forcing it to
be limited by Geany built-in capabilities.

Jiri has for example noted he doesn't want to be built into Geany the
type of project management capability needed to allow accurate enough
includes to be determined to allow accurate symbols.  Thats fine, but
at the moment its also not possible for anyone to add it in a plugin
either.  If Geany is to remain closed to such plugins it will remain
"all languages are poorly handled C" and slip further behind other
tools for newer languages that become more and more "not C".  And I
for one would be sad to see that happen simply because of a refusal to
make Geany open enough.


More information about the Devel mailing list