VisualD's Intellisense not workign with gtk

[Johnson Jones via Digitalmars-d-ide]

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.



>> ------------------------------Part 
>> 2----------------------------
>> I just tried downloading the source code and get >
>> "C:\Program Files (x86)\Microsoft Visual 
>> Studio\2017\Enterprise\\Common7\Tools\vsvars32.bat"
>> 
>> when building build.
>
> I suspect Visual D doesn't build out of the box with VS2017. I 
> still use VS2013 to avoid dependencies in the resulting 
> binaries on newer versions.
>
> See the appveyor.xml how to obtain external dependencies and 
> how to override environment settings.
>
> You might also want it to check the logs on Appveyor that 
> builds with VS2013 and VS2015: 
> https://ci.appveyor.com/project/rainers/visuald/build/1.0.138

ok, I'll see what I can do with it.