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

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



To make it more interesting, you can assume that the full C/C++/Obj-C 
AST is somehow represented with full fidelity in a TM tags array, as a 
given.


Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

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

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

[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 simple dumb lexer and not a semantic-based on, etc) . 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.

Agree with Matthew.

The point of not using the standard Scintilla lexer is to be able to
add semantic information made available for the language support
library in the FT-Plugin.

The major example of this is fixing the current situation where any
name that is a type in any scope is coloured as a type in every other
scope, even if the type is not visible there.

That means that the lexer is intimately tied into the FT-Plugin so it
likely won't run without the FT-Plugin anyway, so actually including
it in the plugin and accessing it via the container lexers interface
looks better than having a separate DLL that won't run by itself
anyway and then has to be sure its loaded at the right time.


Can this support color schemes and custom keywords (although the latter
is probably not very important).

I don't know what SCLEX_CONTAINER is.



It's the built-in (application-provided) lexing support in Scintilla. It 
means "Tell me when, and I'll highlight the source for you". It only 
requires a GTK+ signal from Scintilla rather than having to implement a 
concrete C++ class of ILexer and conforming to some interface in a 
separate DLL, to perform roughly the same task.


http://www.scintilla.org/ScintillaDoc.html#SCN_STYLENEEDED

Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[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, etc) . 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.

Agree with Matthew.

The point of not using the standard Scintilla lexer is to be able to
add semantic information made available for the language support
library in the FT-Plugin.

The major example of this is fixing the current situation where any
name that is a type in any scope is coloured as a type in every other
scope, even if the type is not visible there.

That means that the lexer is intimately tied into the FT-Plugin so it
likely won't run without the FT-Plugin anyway, so actually including
it in the plugin and accessing it via the container lexers interface
looks better than having a separate DLL that won't run by itself
anyway and then has to be sure its loaded at the right time.


Can this support color schemes and custom keywords (although the latter 
is probably not very important).


I don't know what SCLEX_CONTAINER is.

Best regards
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[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 Scintilla's "container
>>> lexers".
>>>
>>> At the minimum, it could have a callback something like:
>>>
>>> gboolean (*highlight)(GeanyPlugin*, GeanyDocument*,
>>> guint start_pos, guint end_pos, gpointer user_data);
>>>
>>> As with Scintilla's "container lexer", it would just tell the provider
>>> what and where to highlight. It might be pointless providing `end_pos`
>>> it could probably just highlight a whole line at time (maybe like
>>> Scintilla's 'style-needed' notification).
>>
>>
>> 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 providing
>> their own full-blown Scintilla lexer library that we just add and use.
>>
>
> The only positive I really see, which in practice probably won't exist, is
> modularity and ability to re-use lexers independent of Geany/ft-plugin (ie.
> for all Scintilla-using apps). I say in practice because at least with my
> `LexClang.so` I needed it to be bound into Geany anyway to get hooks for
> when to re-parse (you can't re-parse a million token C++ file each time
> Scintilla wants to re-colour a line of code). Further, the dynamic lexer
> needs to cooperate with Geany/ft-plugin, or at least deviate from normal
> Scintilla lexers, if it wanted to provide/setup its own lexical
> states/styles (TBD how this part will go).
>
>> Having our own callback means one more indirection, and changing the
>> SciLexer to CONTAINER anyway, so I don't see much advantage just now.
>>
>
> 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 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.

Agree with Matthew.

The point of not using the standard Scintilla lexer is to be able to
add semantic information made available for the language support
library in the FT-Plugin.

The major example of this is fixing the current situation where any
name that is a type in any scope is coloured as a type in every other
scope, even if the type is not visible there.

That means that the lexer is intimately tied into the FT-Plugin so it
likely won't run without the FT-Plugin anyway, so actually including
it in the plugin and accessing it via the container lexers interface
looks better than having a separate DLL that won't run by itself
anyway and then has to be sure its loaded at the right time.

Cheers
Lex

>
> Cheers,
> Matthew Brush
>
>
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

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

Geany must ask the plugin for the answer for each element of
functionality the plugin provides.  This means that those elements
have indeed simply moved "Geany's deficiencies to the plugin space" as
you put it.  This is good and necessary.

Of course moving the problem to plugin space doesn't mean the plugin
can't use Geany facilities where their capabilities fit the
requirement.  But we should not try to expand Geany to handle all
types of functionality.

Like your TM query interface, the plugins should answer the questions
like "whats the autocomplete here", "what calltips are relevant here"
with a flat list of data relevant to the question.

The only place all the symbols should be returned is for the display
in the symbol tree, and for that use I'll defer to Colomban's
suggestion to provide TMTag structures, not for the plugin to access
TM.



> Best regards.
>
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[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:
>>
>> 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
>> entire AST
>> (which is absolutely massive, particularly for C++),
>> convert it to
>> TM tag structures, and then Geany/TM would have to perform
>> some
>> merging logic, would would be more complicated than now if
>> it was
>> to support C++ properly, every single re-parse. My
>> intuition tells
>> me that just won't be fast enough, Clang already jumps through
>> hoops and uses tricks to just build its own AST in-time.
>>
>>
>> I think it would be a disaster performance-wise. The number of
>> AST nodes can be easily 100x more than the amount of tags we
>> have from ctags (we get a single tag for a function now and
>> AST will contain complete tree for the function body) so just
>> this might cost 100x more. In addition all the necessary
>> copies to TM internal representation, having to maintain the
>> tree structure (in TM we use GPtrArrays for everything which
>> are very efficient and during tag merge we try to eliminate
>> even pointer dereferences because those start getting
>> expensive when managing many tags) etc.
>>
>>
>>
>> Let's not outright reject possible solutions based on performance
>> assumptions and guestimations. Performance can be evaluated on an
>> actual implementation. Until then it's simply an invalid argument
>> for this discussion. But FWIW, I don't think performance is the
>> driving aspect.
>>
>>
>> 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 neither ctags, nor TM nor Geany are
>> thread-safe) and all updates have to happen in a really short time period -
>> you cannot make the GUI freeze while the user is typing so you have 100ms
>> at most without any noticeable delay.
>>
>
> I'm saying we can't evaluate performance at this time, because no
> implementation is available. So saying now "uhm I fear it might be too slow
> my guess is that the other one is 100x faster" is just a wild assumption
> that doesn't help except spraying FUD. And outright rejecting a proposal
> based on such assumptions is invalid.
>

100x more nodes of AST than the amount of tags we have isn't any wild
assumption - have a look at the AST picture here:

https://en.wikipedia.org/wiki/Abstract_syntax_tree

and the primitive code below to which it corresponds. The tree has 21
nodes. It's easy to imagine source files with 5x more code per function and
you are at the numbers I'm giving you - we generate 1 tag per function and
the corresponding AST you'll have to walk is 100x bigger.


>
> Please lets evaluate solutions, implement them, and then have an eye on
> performance.


I think I have evaluated this solution and it doesn't seem worth the
effort. Not only because the performance but also I don't know how to store
all the necessary information for any kind of language into TM so code
completion works for any language so that it's compatible with ctags and
any kind of AST. If you do, please tell us but not the way "One solution
can be to have tags hold sufficient information" because it doesn't tell
anything.


>
>
>
>> What's needed from the AST is tags (as you and I mentioned
>> elsewhere, AST is the complete code representation, so much more
>> than what's required currently). Those can be extracted in one
>> pass. I don't see that tags need to be converted back to the
>> original AST.
>>
>>
>> As Matthew said, tags are insufficient for good autocompletion (e.g.
>> consider dynamic languages like Python where you have to infer variable
>> type from the right-hand side of an assignment and based on that generate
>> an autocompletion list).
>>
>
> Tags with incomplete information are insufficient. One solution can be to
> have tags hold sufficient information.
>
> FWIW, unless you actually compile the stuff (for C++), any source code
> analysis will be insufficient for some cases. I was under the impression
> that we do *not* want mandatory compilation, which drags in build system
> implications, for stuff like auto completion.
>

libclang basically compiles it - it performs complete syntax analysis the
same way that would 

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

[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 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 of libclang, it additionally provides helpful
 methods
 for performing IDE-related features on the AST, while say with libvala,
 the
 ft-plugin would be required to perform it's own analysis of the AST to
 implement those feaures, which is still a lot less work than in Geany/TM
 since it has access to the full AST/context and the ft-plugin need not
 fear
 encoding language specific semantics into its logic.
>>>
>>>
>>> How do you pass {C,CXX,CPP}FLAGS to libclang? And where do you get them
>>> from?
>>
>> Libclang needs the full-fat build knowledge that "project" systems on
>> other IDEs provide.  Another reason to keep it separate from Geany.
>
>
> So one would have to adjust the build settings and one or more ft-plugins
> all the time?

I am guessing that one of the reasons Matthew mentioned build settings
access in #1195 is so that the plugins with complex build requirements
can set Geany's simple build system to match their complex one.

>
> IMO, complex build system integration is out of scope for ft-plugins. But I
> see that not all features can be supported properly without build system.

I am not sure I understand you?  That sounds like you are saying that
plugins cannot be allowed to have complex build systems inside the
plugin for its own use, or do I misunderstand?

>
>
> Best regards
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[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 of the compiler is
needed). They literally use the built-in compiler front ends to understand
the code. In the case of libclang, it additionally provides helpful methods
for performing IDE-related features on the AST, while say with libvala, the
ft-plugin would be required to perform it's own analysis of the AST to
implement those feaures, which is still a lot less work than in Geany/TM
since it has access to the full AST/context and the ft-plugin need not fear
encoding language specific semantics into its logic.


How do you pass {C,CXX,CPP}FLAGS to libclang? And where do you get them
from?

Libclang needs the full-fat build knowledge that "project" systems on
other IDEs provide.  Another reason to keep it separate from Geany.


So one would have to adjust the build settings and one or more 
ft-plugins all the time?


IMO, complex build system integration is out of scope for ft-plugins. 
But I see that not all features can be supported properly without build 
system.


Best regards
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[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 language):

int a;
{
 first_piece_of_code_using_a...
 float a;
 second_piece_of_code_using_a 
}

For C/C++ the first piece of code will see `a` as an int and the
second piece of code will see `a` as a float, but there are languages
(Julia for one) where both pieces of code will see `a` as a float.
Again you need language specific knowledge to lookup `a` in the first
piece of code.


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.


Best regards.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[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). They literally use the built-in compiler front ends to understand
>> the code. In the case of libclang, it additionally provides helpful methods
>> for performing IDE-related features on the AST, while say with libvala, the
>> ft-plugin would be required to perform it's own analysis of the AST to
>> implement those feaures, which is still a lot less work than in Geany/TM
>> since it has access to the full AST/context and the ft-plugin need not fear
>> encoding language specific semantics into its logic.
>
>
> How do you pass {C,CXX,CPP}FLAGS to libclang? And where do you get them
> from?

Libclang needs the full-fat build knowledge that "project" systems on
other IDEs provide.  Another reason to keep it separate from Geany.

>
> Best regards
>
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[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 case of libclang, it 
additionally provides helpful methods for performing IDE-related 
features on the AST, while say with libvala, the ft-plugin would be 
required to perform it's own analysis of the AST to implement those 
feaures, which is still a lot less work than in Geany/TM since it has 
access to the full AST/context and the ft-plugin need not fear 
encoding language specific semantics into its logic. 


How do you pass {C,CXX,CPP}FLAGS to libclang? And where do you get them 
from?


Best regards
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[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? 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.

Besides, template instantiation requires compiling the units IIUC, which
is probably not gonna happen ever? At least not on every keystroke as
done currently.



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 of libclang, it additionally 
provides helpful methods for performing IDE-related features on the AST, 
while say with libvala, the ft-plugin would be required to perform it's 
own analysis of the AST to implement those feaures, which is still a lot 
less work than in Geany/TM since it has access to the full AST/context 
and the ft-plugin need not fear encoding language specific semantics 
into its logic.


Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[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 type so it will
look them up correctly.  In parameterised generics, what used to be a
type name is now a type syntax, and no matter how I type it, its the
same.

As an example Geany trying to lookup something like
`template_name::member` to get the type of `member` has to
apply syntax analysis to the `template_name` part and can no
longer just get a name.

And parameterised generics are available in a number of languages, but
with differing syntax (`name{params}` is a popular one for non-{}
languages) and again with differing semantics.  So thats even more
language specific knowledge to be encoded in Geany, either in TM or in
Geany if TM doesn't provide the facility.

Much easier to ask the language specific plugin what
`template_name::member` or `type_name{params}`  is.

>
> Besides, template instantiation requires compiling the units IIUC, which is
> probably not gonna happen ever? At least not on every keystroke as done
> currently.

Well, analysing them yes, and it will probably have to happen in a
separate thread/process, so again it isn't something thats going to be
built-in to Geany.

>
> Best regards.
>
>
>
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[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;
{
first_piece_of_code_using_a...
float a;
second_piece_of_code_using_a 
}

For C/C++ the first piece of code will see `a` as an int and the
second piece of code will see `a` as a float, but there are languages
(Julia for one) where both pieces of code will see `a` as a float.
Again you need language specific knowledge to lookup `a` in the first
piece of code.

Cheers
Lex

>
> Regards,
> Colomban
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[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 should be improved to be able to hold sufficient
information, and plugins should help by providing that data. But *just* the
data, don't offload very specific use cases onto them, this will make us
less flexible in the long run. If Geany has the data, we can implement new
features inside Geany or non-ft-plugins. Otherwise we would have to modify
every single ft-plugin for new features and exclude non-ft-plugins.

The problem isn't having the data, its what you do with the data.  To
repeat two C++ examples I posted on IRC:

namespace foo {
struct A { int a=1; int b=2; };
void f(A& anA, int inc){ anA.a+= inc; }
};

foo::A anA;
std::vector someAs;

The current Geany correctly parses this and shows the correct thing in
the symbols pane, so it has the data, it doesn't even need to use a
plugin for the data.

int i = someAs[1]. // Ok TM show me whatcha got, whats legal here?

Answer: a and b because the vector returns a reference to its template
parameter, here foo::A that has members a and b, you have to expand
the template to find the answer.  This is used all over the standard
library.

f( // no calltip because no f is defined in this namespace
f(anA, // so thats the calltip now?

Answer: void foo::f(A& anA, int inc) even though f() is in namespace
foo, because the first argument is type A which is declared in
namespace foo, ADL then will find foo::f().  This is also used in the
standard library and many other libraries.

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


Besides, template instantiation requires compiling the units IIUC, which 
is probably not gonna happen ever? At least not on every keystroke as 
done currently.


Best regards.


___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[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 neither ctags, nor TM nor
>> Geany are thread-safe) and all updates have to happen in a really
>> short time period - you cannot make the GUI freeze while the user is
>> typing so you have 100ms at most without any noticeable delay.
> 
> I'm saying we can't evaluate performance at this time, because no
> implementation is available. So saying now "uhm I fear it might be too
> slow my guess is that the other one is 100x faster" is just a wild
> assumption that doesn't help except spraying FUD. And outright rejecting
> a proposal based on such assumptions is invalid.

I wouldn't dismiss Jiří's performances remarks that easily :)  Remember
he spent a fair amount of time optimizing it, and has had experience
with huge amount of tags with his project-organizer plugin on large
projects (Linux kernel, anyone?).
And IIUC, he realized that with all the tags *current* parsers generate
(e.g. no local variables, etc.) TM started to struggle too much for it
to be usable.

Sure, we need numbers, but I'm afraid we kinda already have some idea of
what they would be.

Yes, maybe it'd be possible to improve the situation even further, but
it might be a lot of work for very little gain.  I would guess if a e.g.
libclang works with real-size projects is because it has a lot of highly
specific optimizations resulting of a lot of work on their side.  And
why I'm not sure it's even so useful for TM anyway, is that both Lex and
Matthew showed some semantic examples that are both very subtle to deal
with, and highly specific to some languages (here, C++) -- I love Lex's
ADL example, C++ can seem just crazy :)

Regards,
Colomban
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[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, probably for all the reasons Matthew notes.

>
> Cheers,
> Matthew Brush
>
>
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel