On 29 August 2016 at 22:38, Thomas Martitz wrote:
> Am 29.08.2016 um 14:23 schrieb Lex Trotman:
>>
>> 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.
On 2016-08-29 03:17 PM, Thomas Martitz wrote:
Am 29.08.2016 um 17:05 schrieb Jiří Techet:
[...]
There is also another aspect about the proposal that worries me: a
plugin shall provide N features for M languages. And X plugins might be
compete (not even considering the desire that plugins can
Am 29.08.2016 um 17:05 schrieb Jiří Techet:
The solution I have in mind simply allows plugins to pass tags to
Geany which they parsed with more advanced code. The tags itself
would advanced too, to allow for the improvements current TM+ctags
can't offer. Symbol tree, calltips,
On 2016-08-29 05:38 AM, Thomas Martitz wrote:
Am 29.08.2016 um 14:23 schrieb Lex Trotman:
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
Am 29.08.2016 um 14:23 schrieb Lex Trotman:
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
Am 29.08.2016 um 05:14 schrieb Matthew Brush:
Hi All,
Related to my previous mail, and assuming it is somewhat reasonable, I
would like to propose a list of initial features that will be useful
to allow plugins to provide, in no particular order:
I disagree with this approach. This adds
On Mon, Aug 29, 2016 at 5:14 AM, Matthew Brush wrote:
> Hi All,
>
> Related to my previous mail, and assuming it is somewhat reasonable, I
> would like to propose a list of initial features that will be useful to
> allow plugins to provide, in no particular order:
>
>