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

2016-09-01 Thread Lex Trotman
[...]>> >> std::vector has a second parameter, which has a default value so its >> legal to omit it, but the type you will get from an accurate parser to >> store in TM will be the complete type which will be something like >> std::vector not just plain std::vector. >> This is

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

2016-09-01 Thread Thomas Martitz
Am 01.09.2016 um 15:00 schrieb Lex Trotman: [...] It is of course always "possible", after all its a mere matter of programming :) And of course an instantiated class template is just a type, but what is the name of std::vector and std::vector so it can be looked up? vector and vector, with

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

2016-09-01 Thread Matthew Brush
On 2016-09-01 01:55 AM, Thomas Martitz wrote: Am 01.09.2016 um 07:47 schrieb 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

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

2016-09-01 Thread Lex Trotman
[...] >> It is of course always "possible", after all its a mere matter of >> programming :) >> >> And of course an instantiated class template is just a type, but what >> is the name of std::vector and std::vector so it can be looked >> up? > > > vector and vector, with scope being std (I think

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

2016-09-01 Thread Colomban Wendling
Le 31/08/2016 à 03:27, Matthew Brush a écrit : > On 2016-08-30 06:43 AM, Colomban Wendling wrote: >> Le 29/08/2016 à 05:14, Matthew Brush a écrit : >>> […] >> >> I'm really not sure it's a good idea to go the custom callback way. >> IMO, we should first try and see how easy it'd be with plugins

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

2016-09-01 Thread Thomas Martitz
Am 01.09.2016 um 07:47 schrieb 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

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

2016-09-01 Thread Thomas Martitz
Am 01.09.2016 um 08:05 schrieb Lex Trotman: On 1 September 2016 at 15:08, 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

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

2016-09-01 Thread Matthew Brush
On 2016-08-31 11:42 PM, Thomas Martitz wrote: Am 01.09.2016 um 07:17 schrieb Matthew Brush: On 2016-08-31 09:57 PM, Thomas Martitz wrote: Am 01.09.2016 um 02:50 schrieb Matthew Brush: I don't think they'll usually require a "build system" per se, but they definitively need to be told how to

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

2016-09-01 Thread Thomas Martitz
Am 01.09.2016 um 07:17 schrieb Matthew Brush: On 2016-08-31 09:57 PM, Thomas Martitz wrote: Am 01.09.2016 um 02:50 schrieb Matthew Brush: I don't think they'll usually require a "build system" per se, but they definitively need to be told how to compile the code where applicable. For

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

2016-09-01 Thread Matthew Brush
On 2016-08-31 08:42 PM, Lex Trotman wrote: On 31 August 2016 at 11:27, Matthew Brush wrote: On 2016-08-30 06:43 AM, Colomban Wendling wrote: [...] Having our own callback means one more indirection, and changing the SciLexer to CONTAINER anyway, so I don't see much

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

2016-08-31 Thread Matthew Brush
On 2016-08-31 10:47 PM, Matthew Brush wrote: 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

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

2016-08-31 Thread 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

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

2016-08-31 Thread Matthew Brush
On 2016-08-31 10:00 PM, Thomas Martitz wrote: Am 01.09.2016 um 05:42 schrieb Lex Trotman: On 31 August 2016 at 11:27, Matthew Brush wrote: With the `LexClang.so` dynamic lexer I made, dynamic lexers seemed not to fit well (too isolated, too many assumptions that it's a

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

2016-08-31 Thread Thomas Martitz
Am 01.09.2016 um 05:42 schrieb Lex Trotman: On 31 August 2016 at 11:27, Matthew Brush wrote: With the `LexClang.so` dynamic lexer I made, dynamic lexers seemed not to fit well (too isolated, too many assumptions that it's a simple dumb lexer and not a semantic-based on,

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

2016-08-31 Thread Lex Trotman
On 31 August 2016 at 11:27, Matthew Brush wrote: > On 2016-08-30 06:43 AM, Colomban Wendling wrote: >> >> Le 29/08/2016 à 05:14, Matthew Brush a écrit : >>> >>> […] >>> >>> Syntax Highlighting >>> --- >>> >>> Most likely using an API based on/similar to

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

2016-08-31 Thread 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

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

2016-08-31 Thread Jiří Techet
On Wed, Aug 31, 2016 at 1:22 PM, Thomas Martitz wrote: > Am 31.08.2016 um 13:03 schrieb Jiří Techet: > > >> >> On Tue, Aug 30, 2016 at 11:29 PM, Thomas Martitz > > wrote: >> >> Am 30.08.2016 um 21:10 schrieb Jiří Techet: >> >>

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

2016-08-31 Thread Lex Trotman
On 1 September 2016 at 00:55, Thomas Martitz wrote: > Am 31.08.2016 um 16:52 schrieb Lex Trotman: >> >> On 1 September 2016 at 00:43, Thomas Martitz wrote: >>> >>> Am 31.08.2016 um 16:39 schrieb Matthew Brush: I can't speak to all compiler

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

2016-08-31 Thread Thomas Martitz
Am 31.08.2016 um 16:52 schrieb Lex Trotman: On 1 September 2016 at 00:43, Thomas Martitz wrote: Am 31.08.2016 um 16:39 schrieb Matthew Brush: I can't speak to all compiler libraries, but at least libclang, libpython and libvala "compile" the source (well just the front-end

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

2016-08-31 Thread Thomas Martitz
Am 31.08.2016 um 15:31 schrieb Lex Trotman: I love Lex's ADL example, C++ can seem just crazy :) Crazy like a Fox, makes the compiler near impossible, but makes lots of stuff "just work" :) So a much simpler example then (using C syntax to explain since we all know it, but could be any

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

2016-08-31 Thread Lex Trotman
On 1 September 2016 at 00:43, Thomas Martitz wrote: > Am 31.08.2016 um 16:39 schrieb Matthew Brush: >> >> >> I can't speak to all compiler libraries, but at least libclang, libpython >> and libvala "compile" the source (well just the front-end of the compiler is >> needed).

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

2016-08-31 Thread Thomas Martitz
Am 31.08.2016 um 16:39 schrieb Matthew Brush: I can't speak to all compiler libraries, but at least libclang, libpython and libvala "compile" the source (well just the front-end of the compiler is needed). They literally use the built-in compiler front ends to understand the code. In the

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

2016-08-31 Thread Matthew Brush
On 2016-08-31 06:30 AM, Thomas Martitz wrote: Am 31.08.2016 um 13:23 schrieb Lex Trotman: [...] Both of these are C++ specific semantics, (types generated by template instantiation and argument dependent lookup). I don't believe TM should be be expanded to include such knowledge. Why not?

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

2016-08-31 Thread Lex Trotman
> Why not? TM could have separate tags for each known template instance and > know which of these applies to someAs, based on information provided by a > ft-plugin. Then the rest would work. Yes, if Geany can be made to understand that `vector` and `vector< int >` and `vector ` are all the same

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

2016-08-31 Thread Lex Trotman
> I love Lex's ADL example, C++ can seem just crazy :) Crazy like a Fox, makes the compiler near impossible, but makes lots of stuff "just work" :) So a much simpler example then (using C syntax to explain since we all know it, but could be any language): int a; {

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

2016-08-31 Thread Thomas Martitz
Am 31.08.2016 um 13:23 schrieb Lex Trotman: [...] But to be able to do 2) and 3) accurately needs more knowledge of each language semantics than is currently available in Geany or tagmanager. That's right. But it doesn't mean the features should be *entirely* moved into plugin space. TM

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

2016-08-31 Thread Colomban Wendling
Le 31/08/2016 à 13:22, Thomas Martitz a écrit : > Am 31.08.2016 um 13:03 schrieb Jiří Techet: >> […] >> >> No, performance is a very valid point. Tag updates don't happen in a >> background thread in Geany but rather on the main thread (and changing >> this would require lots of modifications as

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

2016-08-31 Thread Lex Trotman
All I really wanted was a way to disable > Scintilla's lexer (ie. switch it to `SCLEX_CONTAINER`) without changing the > filetype in Geany, and without doing it behind Geany's back from the plugin. In fact some of the tools using scintilla and which provide a richer styling do exactly that,

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

2016-08-30 Thread Matthew Brush
On 2016-08-30 06:43 AM, Colomban Wendling wrote: Le 29/08/2016 à 05:14, Matthew Brush a écrit : […] Syntax Highlighting --- Most likely using an API based on/similar to Scintilla's "container lexers". At the minimum, it could have a callback something like: gboolean

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

2016-08-30 Thread Matthew Brush
On 2016-08-30 02:29 PM, Thomas Martitz wrote: Am 30.08.2016 um 21:10 schrieb Jiří Techet: [...] And even if we did this, I don't know how we could handle ASTs of different languages in a generic way because these will differ significantly. One more time, seems I wasn't clear enough yet: I'm

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

2016-08-30 Thread Jiří Techet
On Tue, Aug 30, 2016 at 6:41 PM, Matthew Brush wrote: > On 2016-08-30 08:51 AM, Thomas Martitz wrote: > >> Am 30.08.2016 um 01:53 schrieb Matthew Brush: >> >>> On 2016-08-29 03:17 PM, Thomas Martitz wrote: >>> Am 29.08.2016 um 17:05 schrieb Jiří Techet: >

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

2016-08-30 Thread Matthew Brush
On 2016-08-30 08:51 AM, Thomas Martitz wrote: Am 30.08.2016 um 01:53 schrieb Matthew Brush: 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

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

2016-08-30 Thread Colomban Wendling
Le 30/08/2016 à 17:31, Thomas Martitz a écrit : > Am 30.08.2016 um 03:56 schrieb Lex Trotman: >>> […] > >> Certainly 1) showing symbols in the symbol list, 2) autocomplete and >> 3) calltips are currently available to a degree in Geany. But >> highlighting, build commands and build result

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

2016-08-30 Thread Thomas Martitz
Am 30.08.2016 um 01:53 schrieb Matthew Brush: 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

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

2016-08-30 Thread Thomas Martitz
Am 30.08.2016 um 15:38 schrieb Colomban Wendling: Which brings me to a question - do you plan to generate TMTag(s) and feed them to the tag manager instead of the ctags ones? It shouldn't be that hard and if you do this, you could have the sidebar symbols updated for free. I don't know if

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

2016-08-30 Thread Thomas Martitz
Am 30.08.2016 um 03:56 schrieb Lex Trotman: 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

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

2016-08-30 Thread Colomban Wendling
Le 29/08/2016 à 05:14, Matthew Brush a écrit : > […] > > Syntax Highlighting > --- > > Most likely using an API based on/similar to Scintilla's "container > lexers". > > At the minimum, it could have a callback something like: > > gboolean (*highlight)(GeanyPlugin*,

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

2016-08-30 Thread Colomban Wendling
Le 29/08/2016 à 10:04, Jiří Techet a écrit : > […] > > sounds good. This is much more lightweight than how #1195 and various > other discussions sounded, I'm happy :-). Agreed :) I was a little afraid of seeing a proposal introducing a gazillion GObject interfaces and GIO extension points ^^ >

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

2016-08-29 Thread Lex Trotman
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.

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

2016-08-29 Thread Matthew Brush
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

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

2016-08-29 Thread Thomas Martitz
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,

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

2016-08-29 Thread Matthew Brush
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

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

2016-08-29 Thread Thomas Martitz
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

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

2016-08-29 Thread Thomas Martitz
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

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

2016-08-29 Thread Jiří Techet
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: > >