VisualD's Intellisense not workign with gtk

[Rainer Schuetze via Digitalmars-d-ide]

On 06.08.2017 22:18, Johnson Jones wrote:
> On Sunday, 6 August 2017 at 19:27:26 UTC, Rainer Schuetze wrote:
>>
>>
>> On 06.08.2017 18:31, Johnson Jones wrote:
>>> (this is a bit long of a post so take your time(when you have time, 
>>> I'm in no rush) and get some coffee ;)
>>>
>>>
>>> What about locals not seeming to show up? Not sure if my question got 
>>> answered or not?
>>
>> I think there is some misunderstanding about the interaction between 
>> the debugger, the semantic engine and the compiler generated JSON 
>> information.
>>
>> The short version: there is no interaction at all.
>>
>> The slightly longer version:
>>
>> - the debugger is a component completely different from the editor. It 
>> operates on the debug info built into the executable. This represents 
>> the information from the last successful build, but this is hardly 
>> accessible to the editor. It can get obsolete and wrong if you start 
>> editing.
>>
>> - the JSON information is similar to the debug information in that it 
>> represents the information from the last successful build, but more 
>> accessible to the editor. It gets obsolete and wrong if you start 
>> editing, too. In addition it doesn't include any information about 
>> local variables, so that you have to analyze the code with other means 
>> to make sense of any identifier.
>>
>> - that's the job of the semantic analyzer engine. It updates whenever 
>> you change any of the source code. It figures out what type an 
>> identifier is by following the appropriate lookup rules, and it can 
>> also list its members. So matching it to information also available 
>> elsewhere does not really help, because that's not the difficult part.
>>
>>
> 
> Yeah, but these locals are variables that haven't changed. It's part of 
> a library that never changes so the information should always be up to 
> date and everything should be consistent with respect to those elements.
> 
> If it's the semantic analyzers job to report a locals type and all the 
> sub type info, then it's not doing it's job. It should provide coverage 
> in such a way that things that haven't been modified since the last 
> build(like "external" libraries) should be ok to report information 
> because it's safe to assume it's correct.
> 
> Editing files is an extremely local thing and rarely breaks the 
> semantics of much of the program(it can in extreme cases but usually 
> very rare and less likely the larger the program).
> 
> If it's still a problem, how about eventually adding an option where we 
> can specify certain json paths as being semantically correct and the 
> semantic engine uses that data as if it were, regardless. It is up to 
> the programmer to make it so.
> 
> Hence, for something like phobos or gtk or other libraries we won't be 
> modifying, generate the json, stick it in that dir... and the semantic 
> engine uses it regardless of correctness. It matches the locals types up 
> with it and if they match it presents that info.
> 
> What's the worse that could happen? We get some invalid elements in 
> intellisense? I'm ok with that... as long as they are only wrong if I 
> actually modified the libraries and produced an inconsistent state, 
> which I won't do since I don't modify phobos.

Yeah, getting some additional information from JSON files could work, 
but it's not so easy to make the connection. The JSON file does not list 
any locals, so you still have to make sense of an identifier. If you 
find it's type (not vailable in JSON), listing its members is not a big 
deal.

I think time is better invested at improving the semantic engine, though 
in the long run, the dmd compiler is supposed to be usable as a library 
(but getting it to a point where it can be integrated with an IDE is way 
further ahead IMO).

So, if you can provide full source files instead of single line snippets 
of things that don't work, it will likely be a lot easier to reproduce 
and fix the semantic engine. Also, you might want to add them as reports 
to https://issues.dlang.org/ for component visuald so they don't get lost.