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

[...]>> >> 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 the type you see pri

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

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 s

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

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 lan

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

[...] >> 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 tr

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

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 pro

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

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"

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 support" all the time. We

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

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 c

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

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 libpytho

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

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 advantage just now. Wi

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

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 support" >>> all >>> the time. >>> >>> We just disagree on ho

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

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 d

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

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

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

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 simple dumb lexer and n

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

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 libpython, I don't think it needs any flags. For libval

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

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

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

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, etc) . All I really wan

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

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 libpython, I don't think it needs any flags. For libvala IIRC and libclang (if not using compile_c

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

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 Scintilla's "container >>> l

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

On 2016-08-31 08:15 AM, Jiří Techet wrote: On Wed, Aug 31, 2016 at 1:22 PM, Thomas Martitz wrote: [...] Wait, a AST comprising a million nodes doesn't result in a million autocompletion candidates. Anyway, how does the number relate to our discussion? It appears to me you don't really read w

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

On 2016-08-31 07:55 AM, 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 libraries, but at least libclang, libpython and libvala "compile" the sour

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

> > 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 previ

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

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: >> >> Geany would then merge t

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

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 libraries, but at least libclang, lib

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

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 of the compiler is

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

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 language

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

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). They literally use the

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

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 case

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

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? T

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

> 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 ty

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

> 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; { first_piece_of_code_using_a

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

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 should

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

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 ne

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

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, proba

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

[...] >> 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 should be improved to be able to hold

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

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: Geany would then merge the tags, perhaps giving the plugin ones more

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

On Tue, Aug 30, 2016 at 11:29 PM, Thomas Martitz wrote: > Am 30.08.2016 um 21:10 schrieb Jiří Techet: > > Geany would then merge the tags, perhaps giving the plugin >> ones more >> weight, and store it in TM. >> >> >> I think you underestimate how many tags we're talki

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

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 (*hig

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

On 2016-08-30 06:38 AM, Colomban Wendling wrote: Le 29/08/2016 à 10:04, Jiří Techet a écrit : […] 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 sideb

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

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"

Am 30.08.2016 um 21:10 schrieb Jiří Techet: Geany would then merge the tags, perhaps giving the plugin ones more weight, and store it in TM. I think you underestimate how many tags we're talking here. The example libclang ft-plugin would have to re-walk the enti

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

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: > [...] > There

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

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 M

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

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 handlin

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

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 (not

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

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 plug

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

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 case of tags into t

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

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*, GeanyDoc

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

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"

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. That's just making it

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

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 b

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

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, au

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

> > 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, autocompletion, jump-to-decl can all be improved based

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

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 im

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

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 p

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

> 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 an

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

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 per

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

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: > > > > Syntax Highlighting

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

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: Syntax Highlighting --- Most likely using an API based on/similar to